Недавно проведённый опрос о предпочтениях пользователей в выборе ПО дал результат. После переформирования списка бинарных репозиториев, количество бинарных пакетов было заметно увеличено. Как результат, были убраны блокировки во время установки дополнительных пакетов. В дополнение ко всему, после проведённого голосования, было принято решение включить параллельную установку пакетов. Всё это в совокупности дало впечатляющий результат. В частности, благодаря равномерной загрузке процессорного времени, параллельная установка позволила свести на нет время выполнения установочных скриптов, что дало существенный прирост при установке большого количества пакетов.
Надо заметить, что параллельная сборка пакетов из исходного кода иногда может давать сбои. Лечится либо её отключением (флаг --jobs=1), либо перезапуском процесса установки. Тем не менее, результат настолько хорош, что мы решили постепенно наполнить репозитории всеми популярными программами.
На данный момент Calculate Linux имеет 4 репозитория: “default”, “kde”, “x” и “server”. Собираются пакеты в трёх Stage-сборках: CLD*, CLDX* и CDS+. Таким образом, мы имеем более-менее универсальные варианты установки пакетов. Там, где встречается флаг “kde”, пакет находится в репозитории “kde”, без флага в репозитории “x”, общий пакет в “default”, без поддержки X-ов в “server”.
Насколько вы довольны результатом и какие пакеты вы хотели бы добавить?
Нет проблем с emerge , нет проблем с portage , нет проблем с блокировками … поэтому данный результат для меня не важен
Alexander Tratsevskiy , это ответ на вопрос “Насколько вы довольны результатом” …
Alexander Tratsevskiy, в первой серии <<Репозитории бинарных пакетов>> пользователи перечисляли пакеты, которые доустанавливают сами. Это как вариант ответа на вопрос
какие пакеты вы хотели бы добавить?
И еще, не совсем по теме, но все же:
Каждый раз при обновлении ядра приходится его пересобирать по причине объема памяти 8 гиг. Час времени на пересборку плюс конечная надежность електросети делают этот процесс иногда излишне динамичным.
Наверное, можно было бы комплектовать дистрибутив/предлагать при обновлении ядро, которое уже видит память до 64 гиг, ведь это обычная практика не скажу всех, но многих дистрибутивов.
Илья, из первой серии всё добавлено. Во второй серии вопрос уже по тому чего нет.
Насколько я помню, при включении поддержки памяти >4 Гб производительность ядра падает на 10-15%. На среднем железе пересборка ядра сведётся к 20 минутам, если убрать много лишних опций. Зафиксировать изменения можно в шаблоне используя утилиту cl-kernel.
Александр, увы, ожидаемый ответ.
В моем случае, если сравнивать время на обслуживание страниц по 4 гига и хроническим свопом, если памяти всего 4 гига, то жертва 10% производительности ядра представляется оптимальным компромисом.
Александр, возможно я не совсем корректно выразился
можно было бы комплектовать дистрибутив/предлагать при обновлении ядро
имелось ввиду в дополнение к дефолтному, а не вместо него.
А фиксация изменений в шаблоне время пересборки не уменьшит, да и сам шаблон был бы уместен при множественных входных параметрах, а тут всего-то переключить один переключатень в конфиге.
Без веской причины не хотелось бы создавать альтернативные ветки ядер. Вопрос в целесообразности. Мы выбрали тот вариант, который всегда заведётся и который будет работать на слабых машинах. Если памяти >=8 Гб, то априори компьютер уже мощнее. Ebuild можно перенести себе на диск, собрать из него и забыть об обновлении на длительное время.
Александр, спасибо за ответ.
Моя активность здесь не должна быть расценена, как настойчивость, или каприз. Думаю, вполне подойдет вариант “прения из зала”.
