Вопросы

Calculate Русский
1

Дабы избежать возможных ошибок решил спросить здесь. Сабж: решил сделать себе хорошую, отзывчивую, и главное быструю систему! Решил опять использовать: scratch с fluxbox на борту. ВНИМАНИЕ, много букафф!

  • Утилиты калькулятора заточены под определенное de с которым выпускаются ?! Т.е будут ли у меня проблемы с ними, если вместо: mate,xfce,kde sc4,kde sc5 будет стоять fluxbox ?!

  • Так-как у меня 8гб оперативы не делаю своп. Разбивать диск на разделы планирую с помощью fdisk. Но, я всегда создавал у самого начала диска boot раздел. Некоторые же вопят, что нужно создавать не boot а / мол: корень лучше расположить как можно ближе к началу диска, так как скорость чтения-записи в начале и в конце диска отличается значительно и это хорошо скажется на быстродействии вновь установленной/перенесённой системы. Так, что же лучше создавать у корня ?!

  • Исключительно pf-kernels. Давно их использую и сугубо личный выбор. Как в утилитах калькулятора запретить обновлять/ставить calculate-source ?! А, обновлять только новые пакеты!

  • Фс, reiserfs с прописыванием в fstab: acl,user_xattr,noatime,nodiratime,notail,barrier=flush

  • Как ранее писал у меня 8гб оперативы, то дефолтный своппинг в 60. Т.е большая часть будет просто в воздухе. И это просто послужит: медвежьей услугой. МОжно конечно установить своппинг на меньшие значения. Но. боюсь, что будут фризы. Стоит ли использовать compcache ?! Он в оперативке создает ramdisk в него попадают страницы он их сжимает, что занимает меньший объем и система своппить будет позже.

  • Так-как я планирую использовать pf-kernels то буду собирать ручками. Планирую в ядре отключить: везде где есть слово debug (дебагом не занимаюсь, зачем мне лишнее в ядре), General setup—Profiling support, Kernel hacking —Compile the kernel with frame pointers, ipv6, Processor type and features —Tickless System (Dynamic Ticks) у мня десктоп а не ноут. Ну и в-принципе все, что планирую отключать.

  • Чтобы снизить аппетиты софта к памяти, планирую использовать: prelink -avfmR и если будут проблемы то: prelink -ua

  • Отключение всяких там демонов, настройка числа tcp/ip за определенное время, убирание лишнего из автостарта, настройка iptables и тд.

Такие вот размышления! Какое Ваше фи поэтому поводу ?! Может я что-то упустил, или кто-то может подсказать еще что-то!

2

Так-как у меня 8гб оперативы не делаю своп

Возможно, Вы просто недооцениваете современные хромообразные браузеры. Загнать с которыми в своп даже 8 гигабайт памяти - это лишь вопрос времени и везения.
Я держу на своей 8гб машинке 10гб под своп. Что дает возможность, во-первых, не испытывать проблем при заходе в спячку и выходе из нее, а во-вторых - не слишком напрягаться, открывая очередное окошко в хромиуме.

Планирую в ядре отключить: везде где есть слово debug (дебагом не занимаюсь, зачем мне лишнее в ядре), General setup—Profiling support, Kernel hacking —Compile the kernel with frame pointers, ipv6, Processor type and features —Tickless System (Dynamic Ticks) у мня десктоп а не ноут. Ну и в-принципе все, что планирую отключать

На мой взгляд, самая интересная работа при сборке ядра ручками - это Device Drivers и Networking
Вот уж где есть разгуляться карманной бритве Оккама… да и на производительность это повлияет гораздо сильнее, кмк. Впрочем, отключить то что хотите отключать Вы - тоже неплохая идея, если Вы уверены что оно Вам никогда не потребуется. А то был у меня случай, когда я отключил себе ipv6 - а через полтора года мне его включил провайдер, и я еще месяц не мог вспомнить, почему он у меня именно на этом компе не работает )))))

Ну и еще в рамках дополнительного крохоборства - демоны, которые кажутся лишними, лучше не отключать совсем, а выносить в отдельный контейнер/виртуалку. Это крайне упростит настройку “основного” хоста (например, сколько бы у Вас ни было физических интерфейсов, включая вайфаи, модемы и витухи - можно оставить одного Дункана Маклауда, а все остальное вкупе с самбами, нфс-ами и фаерволлами можно отдать гостевому контейнеру).

А если в качестве контейнера брать LXC на базе alpinelinux - то там затраты на все это дело ограничатся всего несколькими мегабайтами памяти. Дадад, именно так, я не оговорился ))) когда я использовал в качестве “контейнерной” ОС Дебиян, это под мои задачи требовало полтора гигабайта на диске и минимум 128 мегабайт ОЗУ. С alpine же это - 32 мегабайта ОЗУ (есть подозрение, что можно сильно меньше, но я не жмот) и примерно столько же на диске.
Естественно, наличие в компе запущенного LXC потребует чуть более филигранной сборки ядра - но оно того стОит, ей-богу.

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

3

у Вас компьютер родом из начала 90-х по мощности, что-ли?
начерта на всем этом экономить и своими пертурбациями с конфигами “ускорить” железо на пару-тройку процентов?

4

Утилиты калькулятора заточены под определенное de с которым выпускаются ?!

$ eix sys-apps/calculate-utils
[I] sys-apps/calculate-utils [1]
Available versions: (3) 3.4.5.27{tbz2} 3.4.5.28{tbz2} 3.4.5.29{tbz2} **3.4.9999
{client console desktop minimal pxe qt4 PYTHON_TARGETS=“python2_7”}
Installed versions: 3.4.5.29(3){tbz2}(16:31:29 09.03.2016)(client console desktop qt4 -minimal -pxe PYTHON_TARGETS=“python2_7”)

поменяйте флаги -desktop -qt4 (если необходимо) и никаких привязок не будет.

Так, что же лучше создавать у корня ?!

разбивайте как нравится.

Фс, reiserfs с прописыванием в fstab: acl,user_xattr,noatime,nodiratime,notail,barrier=flush

про рейзерфс хочу сразу предупредить: если надумаете /boot или / (с невыделенным бутом) заделать в reiserfs, озадачьтесь включением утилит в initrd. невозможность прочекать / (и соответственно загрузиться), потому что fsck.reiserfs на нём же - это печаль.

5

# утилиты настраивают систему при помощи шаблонов. В отличие от /etc/skel, шаблоны настраивают только то, что умеют. Т.е. /home/<> в идеале не будет содержать настроек пакетов, если эти пакеты не установлены или для них нет настроек.
# /boot выносить смысла нет, это только создаст лишние сложности. Значит ответ - корень )
# если вы посмотрите кому нужен calculate-sources, то увидите, что он нужен только пакету virtual/linux-sources-1, а точнее не он, любое из ядер. Как и pf-sources, calculate-sources от ванильного отличается набором патчей. Вам ничего не мешает использовать свои патчи в calculate-sources взамен получая сборку и установку из emerge.
# reiserтак reiser, почему нет
# в Calculate преднастроен zswap, если есть желание, можете поиграться его настройками.
# debug в calculate-sources и так везде отключён, остальное максимально вынесено в модули.
# prelink в Calculate преднастроен

6

начерта на всем этом экономить и своими пертурбациями с конфигами “ускорить” железо на пару-тройку процентов?

Вы не любите кошек? Значит, Вы просто не умеете их правильно обжаривать до хрустящей корочки…

Экономии “на пару тройку процентов” путем оптимизации можно достигнуть лишь в интерактивных приложениях, скорость работы которых очень сильно зависит от того, насколько быстро Вы сами умеете жать на клаву и елозить мышкой. Офис там какой-нибудь или веб с почтой.

А в том месте, где компьютеру не требуется человек, оптимизацией можно легко достичь повышения производительности, например, в разы. Вспомните описанный тут кем-то из разработчиков впечатляющий результат ускорения работы архиваторов, достигнутый всего лишь правильным выставлением флажка -j в компиляторе.

А если подходить к процессу оптимизации чуть более творчески - то можно добиться увеличения производительности в тысячи и десятки тысяч раз на каких-то задачах. Подумайте, к примеру, над тем, что именно после того как появилась возможность напихать в СОВРЕМЕННЫЕ компьютеры туеву хучу дешевой оперативной памяти – появилась и возможность отдать 1-2 гигабайта этой оперативной памяти под корневую ФС (а в системах, которые заточены именно под это - даже меньше), как это сделано, например, в качестве опционального режима в alpinelinux или в качестве основного режима (т.е. по-другому просто низзя) в Core linux. Поверьте, на фоне тех чудес производительности, которые показывают таким образом сконфигурированные системы, все игрища по замене, допустим, HDD на SSD отходят даже не на второй, а на десятый план и позволяют сэкономить кучу бабла на отказе от покупки никому не нужных, хотя и очень модных сегодня, декоративных кирпичей для вставки в комп.

Такие дела…

7

Вы это все себе дома или в SOHO производите? тогда это просто Ваш энтузиазизм, который в “мегакорпах” обрубается на корень.

меня еще вот это кхм… озадачило : “то можно добиться увеличения производительности в тысячи и десятки тысяч раз на каких-то задачах”. Вы на каком железе работаете? У Вас “Ломоносов” распараллеленный под рукой, или на своей “селероне” достигаете данного?

8

Иван Крузенштерн wrote:

Вы это все себе дома или в SOHO производите? тогда это просто Ваш энтузиазизм, который в “мегакорпах” обрубается на корень.

меня еще вот это кхм… озадачило : “то можно добиться увеличения производительности в тысячи и десятки тысяч раз на каких-то задачах”. Вы на каком железе работаете? У Вас “Ломоносов” распараллеленный под рукой, или на своей “селероне” достигаете данного?

Эх, напрасно Вы тут озадачились. Читали бы повнимательнее что написано - и сами бы смекнули, что железо к количеству РАЗ, В КОТОРЫЕ увеличивается производительность, вообще не имеет отношения. Доступ к RAM в десятки тысяч раз быстрее доступа к SSD на практически любом железе, кроме самого-самого древнего (там, вероятно, всего лишь в тысячи) - поэтому и производительность на задаче загрузки программ увеличивается в одинаковое количество раз что на целероне, что на крее…

А так - да, дома и в SOHO. Впрочем, насчет обрубания энтузиазма у корпораций-монстров Вы тоже не правы. В бытность мою директором в одной широко известной транснациональной корпорации - тамошние айтишники с огромным уважением относились к возможности увеличения производительности мегажелезок на их собственных рабочих местах. Хотя по отношению к продакшен-серверам такие вольности и впрямь не допускались (ну кто бы мог подмать).