[devel] печальные последствия перехода на rpm-4.13

[devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

Уважаемые мужчины!

Вследствие перехода на rpm-4.13 в вашем национальном дистрибутиве
наблюдается многократное замедление работы.

Вот как сканировал пакеты старый rpm:

$ killall -STOP ktorrent chromium
$ rpmpeek /var/cache/apt/archives/rpm_4.0.4-alt101.M80P.1_x86%5f64_1484665077.rpm \
	cp -pv ./usr/lib/rpm/rpmq /tmp
'./usr/lib/rpm/rpmq' -> '/tmp/rpmq'
$ cd /klad/Sisyphus/files/x86_64/RPMS
$      /tmp/rpmq -p *.rpm >/dev/null
$ time /tmp/rpmq -p *.rpm >/dev/null
0.85s user 0.31s system 99% cpu 1.166 total

Вот как сканирует пакеты новый rpm:

$      rpmquery -p *.rpm >/dev/null
$ time rpmquery -p *.rpm >/dev/null
3.51s user 0.25s system 99% cpu 3.757 total

Сканирует в четыре раза дольше - вместо '0.85 user' стало '3.51 user'.
Предварительный осмотр показывает, что rpm теперь вычисляет какие-то
хитрые SHA1-суммы.

Но это полбеды, а настоящий масштаб бедствия становится понятен, если
посмотреть, что происходит с виртуальной памятью.

Старый rpm сканировал пакеты так:

$ sudo sysctl vm.drop_caches=3
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       4582       3283          0          1       1601
-/+ buffers/cache:       2979       4886
Swap:        32763       3176      29586
$ time /tmp/rpmq -p *.rpm >/dev/null
2.06s user 1.85s system 2% cpu 3:04.51 total
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       5247       2619          0         25       2199
-/+ buffers/cache:       3021       4844
Swap:        32763       3176      29586

То есть при сканировании x86_64 пакетов отъедалось примерно 600 Мб
буферного кеша.

Новый rpm сканирует пакеты так:

$ sudo sysctl vm.drop_caches=3
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       4580       3286          0          1       1602
-/+ buffers/cache:       2976       4889
Swap:        32763       3176      29586
$ cd /klad/Sisyphus/files/x86_64/RPMS
$ time rpmquery -p *.rpm >/dev/null
4.66s user 1.89s system 3% cpu 3:13.99 total
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       6534       1331          0         28       3482
-/+ buffers/cache:       3023       4843
Swap:        32763       3176      29586

Новый rpm при сканировании x86_64 пакетов отъел 1880 Мб, более чем
в 3 раза больше старого.  Мужчины, прогресс пришел в ваш дом!

Рассмотрим пример прогресса на конкретном пакете.  Я вот для себя
собираю пакет ffmpeg, потому что в вашем национальном дистрибутиве его
немає.

$ linux-fadvise ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm POSIX_FADV_DONTNEED
...
$ /tmp/rpmq -p ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm
ffmpeg-3.1.6-alt0
$ linux-fincore ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm |tail -1
total cached size: 8,192

С новым rpm:

$ linux-fadvise ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm POSIX_FADV_DONTNEED
...
$ rpmquery -p ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm
ffmpeg-3.1.6-alt0.x86_64
$ linux-fincore ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm |tail -1
total cached size: 49,152

У пакета ffmpeg маленький заголовок, потому что в нем находится только
программа ffmpeg (плюс еще ffplay и ffprobe) и несколько man-страниц.
Старому rpm нужно было 2 страницы виртуальной памяти, новому - 12.

Всё это конечно же происходит из-за readahead.  Я когда-то делал патч
для отключения readahead во время загрузки заголовка:
http://git.altlinux.org/people/at/packages/rpm.git?a=commitdiff;h=66b17f5f
На новый rpm его не портировали.

Правда, этот патч мне не очень нравится, потому на время загрузки
заголовка readahead отключается полностью.  Теоретически этом может
привести к тому, что для загрузки заголовка может потребоваться
несколько physical reads.  Но на практике их не требуется (ср. total
time у /tmp/rpmq и rpmquery) - вероятно, выручает встроенный кеш
внутри самого жесткого диска.

* * *

В связи со всем этим безобразием более актуально встает вопрос о
кешировании заголовков.  Пожалуй, напишу об этом отдельным письмом.

Re: [devel] печальные последствия перехода на rpm-4.13

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

Hi,

On Wed, Jan 25, 2017 at 07:48:12AM +0300, Alexey Tourbin wrote:
> Уважаемые мужчины!
> 
> Вследствие перехода на rpm-4.13 в вашем национальном дистрибутиве
> наблюдается многократное замедление работы.
> 
> Вот как сканировал пакеты старый rpm:
[...]
> Предварительный осмотр показывает, что rpm теперь вычисляет какие-то
> хитрые SHA1-суммы.

Никакой хитрости, оно сравнивает SHA1HEADER с реальностью.  Мне не кажется
это совсем плохой идеей, а для чтения тысяч файлов всегда можно сделать
%__vsflags = %__vsflags|_RPMVSF_NODIGESTS, например 0xf0f00.

> Но это полбеды, а настоящий масштаб бедствия становится понятен, если
> посмотреть, что происходит с виртуальной памятью.
[...]

Спасибо за исследование!

> У пакета ffmpeg маленький заголовок, потому что в нем находится только
> программа ffmpeg (плюс еще ffplay и ffprobe) и несколько man-страниц.
> Старому rpm нужно было 2 страницы виртуальной памяти, новому - 12.
> 
> Всё это конечно же происходит из-за readahead.  Я когда-то делал патч
> для отключения readahead во время загрузки заголовка:
> http://git.altlinux.org/people/at/packages/rpm.git?a=commitdiff;h=66b17f5f
> На новый rpm его не портировали.

Да, портировалось необходимое, а такие вещи к сожалению остались
до появления необходимости. :)

Со спортированным патчем (см task #177147) на rpmquery
-p ~/chromium-55.0.2883.75-alt1.x86_64.rpm получается:

-total cached size: 245,760
+total cached size: 77,824

Раньше были те же 77,824.

> Правда, этот патч мне не очень нравится, потому на время загрузки
> заголовка readahead отключается полностью.

В контексте сборочницы этот патч очень важен когда кэша нет.  Мы даже с
ним теряем минут, кажется, 40 на создание кэша.

> Теоретически этом может
> привести к тому, что для загрузки заголовка может потребоваться
> несколько physical reads.  Но на практике их не требуется (ср. total
> time у /tmp/rpmq и rpmquery) - вероятно, выручает встроенный кеш
> внутри самого жесткого диска.
>
> * * *
> 
> В связи со всем этим безобразием более актуально встает вопрос о
> кешировании заголовков.  Пожалуй, напишу об этом отдельным письмом.

Если речь в первую очередь о сборочнице, то, возможно, стоит задуматься о
патчинге apt-овых индексов (вместо генерации их с нуля).  Остальные
клиенты gb-sh-rpmhdrcache вполне могли бы патчить то, что у них есть -- и
генератор useful-files и генератор contents_index.
Понятно, что единственной загвоздкой в патчинге индексов являются именно
useful-files.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

2017-01-25 20:42 GMT+03:00 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>:
> Hi,
>
> On Wed, Jan 25, 2017 at 07:48:12AM +0300, Alexey Tourbin wrote:
>> Уважаемые мужчины!
>>
>> Вследствие перехода на rpm-4.13 в вашем национальном дистрибутиве
>> наблюдается многократное замедление работы.
>>
>> Вот как сканировал пакеты старый rpm:
> [...]
>> Предварительный осмотр показывает, что rpm теперь вычисляет какие-то
>> хитрые SHA1-суммы.
>
> Никакой хитрости, оно сравнивает SHA1HEADER с реальностью.  Мне не кажется
> это совсем плохой идеей, а для чтения тысяч файлов всегда можно сделать
> %__vsflags = %__vsflags|_RPMVSF_NODIGESTS, например 0xf0f00.

Есть какой-то принцип, в соответствии с которым имеют смысл только
иерархически скоординированные сравнения с реальностью; а любые вообще
проверки дороже assert() тогда объявляются wasteful. Например, если
контрольная сумма проверяется на протоколе более высокого уровня, то
нет уже никакого смысла проверять контрольные суммы на канальном
уровне; если только канальный уровень не может гораздо быстрее
запросить повторную передачу.

Может, кто-нибудь из подписчиков напомнит мне, как называется принцип,
по которому проверки на более высоком уровне делают ненужными проверки
на нижележащих уровнях?

Короче, идея "всё время что-нибудь проверять" довольно глупа. Вместо
нее есть другая идея: "проверить как следует, но только один раз".  В
случае с обновлением пакетов это означает "проверять подпись
репозитория".  Если репозиторий прошел проверку и был криптографически
подписан, то все остальные проверки на клиенте уже абсолютно ничего не
добавляют.

> Если речь в первую очередь о сборочнице, то, возможно, стоит задуматься о
> патчинге apt-овых индексов (вместо генерации их с нуля).  Остальные
> клиенты gb-sh-rpmhdrcache вполне могли бы патчить то, что у них есть -- и
> генератор useful-files и генератор contents_index.
> Понятно, что единственной загвоздкой в патчинге индексов являются именно
> useful-files.

Зачем патчить аптовые индексы? Заново их создать - это несколько
секунд всего. Самая дорогая операция - это xz-сжатие, около минуты.
Для внутренних нужд надо мигрировать на другое сжатие, то есть на zstd
вместо xz.  У меня были работоспособные подвижки в этом направлении
еще осенью: https://github.com/svpv/apt-repo-tools/commit/64029fc8

В общем, если бывшая фирма альт линукс хочет проинвестировать в
развитие своей уникальной технологии, то значит она благоволит мне
писать по электронной почте, и уникальная технология как Шариков^W
нечего делать разовьется.

Re: [devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

2017-02-28 19:19 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>:
> В общем, если бывшая фирма альт линукс хочет проинвестировать в
> развитие своей уникальной технологии, то значит она благоволит мне
> писать по электронной почте, и уникальная технология как Шариков^W
> нечего делать разовьется.

Что-то мне не пишут неблагодраные граждане, которые обогатились на моей работе.

Re: [devel] печальные последствия перехода на rpm-4.13

[Andrew Clark]

4 марта 2017 г., 10:31 пользователь Alexey Tourbin
<alexey.tourbin@gmail.com> написал:

> Что-то мне не пишут неблагодраные граждане, которые обогатились на моей работе.

Это что бы Вы от непомерной гордыни преждевременно не скончались.


-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: [devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

2017-03-04 11:08 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:
> 4 марта 2017 г., 10:31 пользователь Alexey Tourbin
> <alexey.tourbin@gmail.com> написал:
>
>> Что-то мне не пишут неблагодраные граждане, которые обогатились на моей работе.
>
> Это что бы Вы от непомерной гордыни преждевременно не скончались.

Мужчина Андрю Кларк, с вами разговаривать смешно. Вы признаете Алексея
Турбина не достойным вклада в Альт линукса, а червем земли.  Всего вам
хорошего.

Re: [devel] genbasedir (was: печальные последствия перехода на rpm-4.13)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Tue, Feb 28, 2017 at 07:19:00PM +0300, Alexey Tourbin wrote:
> 2017-01-25 20:42 GMT+03:00 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>:
[...]
> > Если речь в первую очередь о сборочнице, то, возможно, стоит задуматься о
> > патчинге apt-овых индексов (вместо генерации их с нуля).  Остальные
> > клиенты gb-sh-rpmhdrcache вполне могли бы патчить то, что у них есть -- и
> > генератор useful-files и генератор contents_index.
> > Понятно, что единственной загвоздкой в патчинге индексов являются именно
> > useful-files.
> 
> Зачем патчить аптовые индексы? Заново их создать - это несколько
> секунд всего.

Это для Сизифа несколько секунд?  При условии что всё в памяти сидит?

> Самая дорогая операция - это xz-сжатие, около минуты.
> Для внутренних нужд надо мигрировать на другое сжатие, то есть на zstd
> вместо xz.  У меня были работоспособные подвижки в этом направлении
> еще осенью: https://github.com/svpv/apt-repo-tools/commit/64029fc8

zstd, конечно, значительно быстрее чем xz, и для genbasedir --bloat
xz вполне можно было бы заменить.  Но медленный genbasedir --bloat
используется не всегда (gb-task-gen-task-repo не в счёт), а вот обычный
genbasedir - для каждого задания, дошедшего до интересующей нас стадии.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] печальные последствия перехода на rpm-4.13

[Andrew Clark]

4 марта 2017 г., 12:51 пользователь Alexey Tourbin
<alexey.tourbin@gmail.com> написал:

> Мужчина Андрю Кларк, с вами разговаривать смешно.

Может быть. Но с Вами бесполезно - это хуже.

>  Вы признаете Алексея Турбина не достойным вклада в Альт линукса, а червем земли.

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

> Всего вам хорошего.

И Вам не кашлять.

-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: [devel] уникальная технология (was: печальные последствия перехода на rpm-4.13)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Tue, Feb 28, 2017 at 07:19:00PM +0300, Alexey Tourbin wrote:
[...]
> В общем, если бывшая фирма альт линукс хочет проинвестировать в
> развитие своей уникальной технологии, то значит она благоволит мне
> писать по электронной почте, и уникальная технология как Шариков^W
> нечего делать разовьется.

Выключение проверки дайджестов и zstd вместо xz для --bloat это хорошо,
конечно, но так вы слона не продадите.
Напишите тут, какие у вас есть предложения по развитию уникальной
технологии, может, это кого-нибудь заинтересует.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

2017-03-04 13:50 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:
> 4 марта 2017 г., 12:51 пользователь Alexey Tourbin
> <alexey.tourbin@gmail.com> написал:
>
>> Мужчина Андрю Кларк, с вами разговаривать смешно.
>
> Может быть. Но с Вами бесполезно - это хуже.
>
>>  Вы признаете Алексея Турбина не достойным вклада в Альт линукса, а червем земли.
>
> Я признаю Алексея Турбина как любителя почесать языком,
> и пространно порассуждать на тему какие все "гандоны, а он воздушный шарик".
> Тщеславие так и прет.

В приватных беседах работу Алексея Турбина оценивают несколько выше:
"он сказал, что у него есть решения и технологии, которые позволят
создать линейку продуктов"
http://www.cnews.ru/news/top/2016-12-02_pokinuvshaya_alt_linuks_komanda_poluchila_na

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

Re: [devel] печальные последствия перехода на rpm-4.13

[Andrew Clark]

6 марта 2017 г., 10:37 пользователь Alexey Tourbin
<alexey.tourbin@gmail.com> написал:
> 2017-03-04 13:50 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:

> В приватных беседах работу Алексея Турбина оценивают несколько выше:
> "он сказал, что у него есть решения и технологии, которые позволят
> создать линейку продуктов"
> http://www.cnews.ru/news/top/2016-12-02_pokinuvshaya_alt_linuks_komanda_poluchila_na

Полная цитата:
Коллектив Новодворского в ИВК знали еще с 2001 г., когда компания
заказала у него разработку межсетевого экрана на базе ядра Linux.
«Когда в середине 2015 г. пришел Алексей, он сказал, что у него есть
решения и технологии, которые позволят создать линейку продуктов
в течение года, и на это нужно 100 млн, — говорит Сизоненко. — Так
появилась компания “Базальт”».

Оценивают не работу Алексея Турбина, а работу Алексея Новодворского, который
смог привлечь инвестиции. Чесать языком Вы мастак, да еще и врете.
К тому же ссылки на днище портал cnews - это моветон. Но Вам можно.

> Очень интересно, почему вы считаете меня любителем почесать языком.
> Кроме некоторой неосведомленности и брехливоси, на которые я вам уже
> указывал.

Да-да, как там delta rpm? По прежнему "не нужен" как и остальное развитие
rpm от RH в принципе?

-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: [devel] уникальная технология (was: печальные последствия перехода на rpm-4.13)

[Alexey Tourbin]

2017-03-05 4:42 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
> On Tue, Feb 28, 2017 at 07:19:00PM +0300, Alexey Tourbin wrote:
> [...]
>> В общем, если бывшая фирма альт линукс хочет проинвестировать в
>> развитие своей уникальной технологии, то значит она благоволит мне
>> писать по электронной почте, и уникальная технология как Шариков^W
>> нечего делать разовьется.
>
> Выключение проверки дайджестов и zstd вместо xz для --bloat это хорошо,
> конечно, но так вы слона не продадите.
> Напишите тут, какие у вас есть предложения по развитию уникальной
> технологии, может, это кого-нибудь заинтересует.

Я не продаю слонов. Я занимаюсь перспективным мышлением.

Одна из идей - цикл сборки пакета должен быть минимальным на стороне
сборочницы. Минута на xz-сжатие - не годится.

Есть еще идея, чтобы применить к сборочной системе принципы квантовой
механики. Репозиторий может находится сразу в нескольких состояниях,
как в double-slit experiment. Вопрос состоит, какая выгода может быть
извлечена из откладывания коллапаса пси-функции. Эта выгода есть, даже
если она не очевидна с первого взгляда.

Другая интересная идея - это попытка запрячь #ccache во всю эту
систему компиляции. Я знаю only full well о скептическом отношении
некоторых хитрых граждан к #ccache. Тем не менее, ccache подвержен
исправлениям. Я его отпрофилировал, и он стал работать в 2 раза
быстрее https://github.com/svpv/ccache/commits/master В #ccache есть
еще один fatal flaw, о котором я кстати рассказывал Глебу, но только
потому что он меня попросил. Без исправления этого fatal flaw
использовать его на мой взгляд нельзя.

Я вам писал еще доклад про типизацию ABI. Линкер он ведь интересуется,
он суется туда куда его не просят, он подцепляет старую или новую
функцию, потому что, как Дреппер говорил, "you have to be a moron to
relink without checking". По этому самому принципу, самое слабое звено
возникает при линковке, прототипа при линковке нету, и мы вообще не
знаем с чем мы линкуемся или нет. У меня в докладе были доводы, почему
даже при таком неопределенном положении "линковка по имени" может
иметь смысл.

В общем, как пел Высоцкий, "люди добрые простят, а злые пусть осудят",
поработать над развитием уникальной технологии, без всяких прошлых
обид, мне может быть и хотелось бы. Если надо написать какую-нибудь
умную заявку на грант, то за мной сочинить креатив дела не станет. С
другой стороны, вся эта "academic writing", это какая-то умная
показуха. Может, надо и попроще, прямо совсем по смыслу.

Re: [devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

2017-03-06 10:47 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:
> 6 марта 2017 г., 10:37 пользователь Alexey Tourbin
> <alexey.tourbin@gmail.com> написал:
>> 2017-03-04 13:50 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:
>
>> В приватных беседах работу Алексея Турбина оценивают несколько выше:
>> "он сказал, что у него есть решения и технологии, которые позволят
>> создать линейку продуктов"
>> http://www.cnews.ru/news/top/2016-12-02_pokinuvshaya_alt_linuks_komanda_poluchila_na
>
> Полная цитата:
> Коллектив Новодворского в ИВК знали еще с 2001 г., когда компания
> заказала у него разработку межсетевого экрана на базе ядра Linux.
> «Когда в середине 2015 г. пришел Алексей, он сказал, что у него есть
> решения и технологии, которые позволят создать линейку продуктов
> в течение года, и на это нужно 100 млн, — говорит Сизоненко. — Так
> появилась компания “Базальт”».
>
> Оценивают не работу Алексея Турбина, а работу Алексея Новодворского, который
> смог привлечь инвестиции. Чесать языком Вы мастак, да еще и врете.
> К тому же ссылки на днище портал cnews - это моветон. Но Вам можно.

Новодворский не написал ни одной строчки кода, он духовный лидер,
абсолютно никто. Разработкой уникальной технологии, описанной по
следующей ссылке, занимался в первую очередь я. Думаю, ключевую роль в
получении инвестиций сыграла именно эта технология:
https://www.basealt.ru/base/repository/

И зачем вы это пишете, вписываетесь за двуногих мужчин, вы брешете на
меня то, что они сами не хотят мне из приличия сказать. Потому что
никакого приличия у вас нету. А у них - есть. Хотя бы и остаточное.

>> Очень интересно, почему вы считаете меня любителем почесать языком.
>> Кроме некоторой неосведомленности и брехливоси, на которые я вам уже
>> указывал.
>
> Да-да, как там delta rpm? По прежнему "не нужен" как и остальное развитие
> rpm от RH в принципе?

Я написал большой документ о развитии rpm еще в 2012 году.
https://github.com/svpv/rpm-proposal/blob/master/rpm-proposal.pdf
Всякий дальнейший разговор очень осложняется тем, что вы почитаете за
честь очень громко гавкать. Вам кажется это убедительным.

Re: [devel] печальные последствия перехода на rpm-4.13

[Andrew Clark]

6 марта 2017 г., 15:28 пользователь Alexey Tourbin
<alexey.tourbin@gmail.com> написал:

> Новодворский не написал ни одной строчки кода, он духовный лидер,
> абсолютно никто. Разработкой уникальной технологии, описанной по
> следующей ссылке, занимался в первую очередь я.

Из приведенной Вами ссылки это никак не следует.

> Думаю, ключевую роль в получении инвестиций сыграла именно эта технология:
> https://www.basealt.ru/base/repository/

То есть Вы не уверены? Зачем тогда утверждаете?

> И зачем вы это пишете, вписываетесь за двуногих мужчин, вы брешете на
> меня то, что они сами не хотят мне из приличия сказать.

Почему Вы мне приписываете то, что я не делаю? Я ни за кого, как Вы
изволите выражаться "не вписываюсь". "вы брешете" - я пишу, то, что думаю.

>  Потому что никакого приличия у вас нету. А у них - есть. Хотя бы и остаточное.

У Вас приличия не занимать, конечно же.

> Я написал большой документ о развитии rpm еще в 2012 году.
> https://github.com/svpv/rpm-proposal/blob/master/rpm-proposal.pdf

Это надо не на русском было писать, а на английском и в рассылку разработчиков
rpm закидывать. Пока Вы свои домыслы излагаете, есть люди которые
развивают. И это не Альт.
Такова селяви на сегодняшний день. Вспомнить можно, к примеру, про
участь deepsolver , хотя разговоров
было про него немало (https://www.opennet.ru/opennews/art.shtml?num=34337).
В результате, развитие alt-rpm и дальше продолжилось
в виде бесконечного прикладывания патчей
(https://packages.altlinux.org/en/Sisyphus/srpms/apt/changelog),
а deepsolver тихо гниет в забытой репе.
(http://git.altlinux.org/people/msp/packages/?p=deepsolver.git;a=summary)
И решение переходить на rpm 4.13 было абсолютно верным, хоть и
весьма запоздалым.

> Всякий дальнейший разговор очень осложняется тем, что вы почитаете за
> честь очень громко гавкать. Вам кажется это убедительным.

Скажите пожалуйста, Вам обязательно выставлять на всю рассылку себя мудаком?
Манера ведения разговора в переписках выдает в Вас дешевого позера,
который не может решить свои проблемы/вопросы/претензии спокойно и рассудительно
в личной переписке? Почему Вы считаете нужным и правильным исходить на
говно в рассылке? Впрочем, можете не трудится отвечать. Хотя нет, решительно
ответьте, что бы оставить за собой последнее слово!

-- 
Talk is cheap, show me the code (c) Linus Torvalds

[devel] Administrativa (was Re: печальные последствия перехода на rpm-4.13)

[Alexey Gladkov]

On Mon, Mar 06, 2017 at 03:59:39PM +0300, Andrew Clark wrote:
> Скажите пожалуйста, Вам обязательно выставлять на всю рассылку себя ...

Этот список рассылки посвящён обсуждению технических вопросов. Здесь не место
для оскорблений. Пожалуйста воздержитесь от подобного в будущем.

Это касается всех участников этого треда.

-- 
Rgrds, legion

Re: [devel] genbasedir (was: печальные последствия перехода на rpm-4.13)

[Alexey Tourbin]

2017-03-04 13:46 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
>> Зачем патчить аптовые индексы? Заново их создать - это несколько
>> секунд всего.
>
> Это для Сизифа несколько секунд?  При условии что всё в памяти сидит?

При условии, что вся память перечитывается из буферного кеша,
перегенерация всего pkglist.classic из одно в другое место занимает
около двух секунд. Это практически a no-op.

Чем вас можно убедить? Я много раз запускал что-то типа вроде
$ time LD_PRELOAD=rpmhdrcache.so ./genpkglist --no-scan
/klad/Sisyphus/x86_64 classic

Он занимает у меня ровно две секунды. Волнует, нежели язвит!

Re: [devel] печальные последствия перехода на rpm-4.13

[Alexey Tourbin]

2017-03-06 15:59 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:
> 6 марта 2017 г., 15:28 пользователь Alexey Tourbin
> <alexey.tourbin@gmail.com> написал:
>
>> Новодворский не написал ни одной строчки кода, он духовный лидер,
>> абсолютно никто. Разработкой уникальной технологии, описанной по
>> следующей ссылке, занимался в первую очередь я.
>
> Из приведенной Вами ссылки это никак не следует.

Вы хотите вынудить меня на утверждение, что из приведенной ссылки
следует что-то огромное, и что государство - это я.

>> Думаю, ключевую роль в получении инвестиций сыграла именно эта технология:
>> https://www.basealt.ru/base/repository/
> То есть Вы не уверены? Зачем тогда утверждаете?

Вы охотнее беретесь интерпретировать мои интенции, а не смыслы.
Смыслы кажутся вам незначительными, а интенции вы интерпретируете как
огромные претензии.  Всё это не так.

>> И зачем вы это пишете, вписываетесь за двуногих мужчин, вы брешете на
>> меня то, что они сами не хотят мне из приличия сказать.
>
> Почему Вы мне приписываете то, что я не делаю? Я ни за кого, как Вы
> изволите выражаться "не вписываюсь". "вы брешете" - я пишу, то, что думаю.

Это очень хорошо, что вы пишете, что думаете. К сожалению, вы
поддерживаете чужую неправильную точу зрения. Может, у вас есть
обостренное чувство справедливости, и то что вы на меня брешете это
кажется вам остроумным полемическим приемом. Дорого этот прием не
стоит, though.

Re: [devel] уникальная технология (was: печальные последствия перехода на rpm-4.13)

[Alexey Tourbin]

2017-03-06 11:55 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>:
> Другая интересная идея - это попытка запрячь #ccache во всю эту
> систему компиляции. Я знаю only full well о скептическом отношении
> некоторых хитрых граждан к #ccache. Тем не менее, ccache подвержен
> исправлениям. Я его отпрофилировал, и он стал работать в 2 раза

Мужчина, вы зря обиделись на меня, если почуяли, что вас обозвали
хитрым гражданином. Настоящей ненависти к хитрым гражданам у меня
нету, это всё дурной прикол, вызванный сладким чувством мести. Пишите
короче, может сделаем что-нибудь умное.

Re: [devel] ccache (was: уникальная технология)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

On Mon, Mar 06, 2017 at 11:55:58AM +0300, Alexey Tourbin wrote:
> Другая интересная идея - это попытка запрячь #ccache во всю эту
> систему компиляции. Я знаю only full well о скептическом отношении
> некоторых хитрых граждан к #ccache. Тем не менее, ccache подвержен
> исправлениям. Я его отпрофилировал, и он стал работать в 2 раза
> быстрее https://github.com/svpv/ccache/commits/master В #ccache есть
> еще один fatal flaw, о котором я кстати рассказывал Глебу, но только
> потому что он меня попросил. Без исправления этого fatal flaw
> использовать его на мой взгляд нельзя.

Я могу предположить, при каком использовании ccache возникает fatal flaw,
но лучше будет, если вы сами расскажете.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] genbasedir (was: печальные последствия перехода на rpm-4.13)

[Evgeny Sinelnikov]

6 марта 2017 г., 17:21 пользователь Alexey Tourbin
<alexey.tourbin@gmail.com> написал:
> 2017-03-04 13:46 GMT+03:00 Dmitry V. Levin <ldv@altlinux.org>:
>>> Зачем патчить аптовые индексы? Заново их создать - это несколько
>>> секунд всего.
>>
>> Это для Сизифа несколько секунд?  При условии что всё в памяти сидит?
>
> При условии, что вся память перечитывается из буферного кеша,
> перегенерация всего pkglist.classic из одно в другое место занимает
> около двух секунд. Это практически a no-op.
>
> Чем вас можно убедить? Я много раз запускал что-то типа вроде
> $ time LD_PRELOAD=rpmhdrcache.so ./genpkglist --no-scan
> /klad/Sisyphus/x86_64 classic
>
> Он занимает у меня ровно две секунды. Волнует, нежели язвит!

А это решение опакечено?

Последний раз, когда я пытался его воспроизвести в своём локальном
окружении, "что-то снова пошло не так". Это было давно, поэтому
спрашивать: "Почему я тогда не спросил?", - уже не имеет смысла.
Сейчас rpmhdrcache.so каким образом доступен для использования?

PS: Кстати, была одна штука, не уверен, что именно в ней дело, но всё
же. Задача была такая - использовать rpmhdrcache.so не для полного
набора пакетов Sisyphus/x86_64 classic, а для расширений
Sisyphus/x86_64 addon unstable.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ccache (was: уникальная технология)

[Evgeny Sinelnikov]

7 марта 2017 г., 14:26 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Mon, Mar 06, 2017 at 11:55:58AM +0300, Alexey Tourbin wrote:
>> Другая интересная идея - это попытка запрячь #ccache во всю эту
>> систему компиляции. Я знаю only full well о скептическом отношении
>> некоторых хитрых граждан к #ccache. Тем не менее, ccache подвержен
>> исправлениям. Я его отпрофилировал, и он стал работать в 2 раза
>> быстрее https://github.com/svpv/ccache/commits/master В #ccache есть
>> еще один fatal flaw, о котором я кстати рассказывал Глебу, но только
>> потому что он меня попросил. Без исправления этого fatal flaw
>> использовать его на мой взгляд нельзя.
>
> Я могу предположить, при каком использовании ccache возникает fatal flaw,
> но лучше будет, если вы сами расскажете.
>

Да! Я тоже хочу ccache в hasher'е. И, может быть, даже пусть
"возникает fatal flaw". Но я не уверен. Было бы неплохо уточнить не
только "при каком использовании ccache" он возникает, но и что это,
вообще, значит.


-- 
Sin (Sinelnikov Evgeny)