Начало разработки Calculate Utilities 3.1

Выпуск дистрибутива - прекрасное время для того, чтобы расслабиться заняться более глобальными задачами. На этот раз такой задачей оказался вывод списка значений переменных… Для многих не секрет, что утилиты в своей работе используют внутренние переменные, которые получают свои значения исходя из переданных параметров, настроек системы, аппаратных особенностей и т.д. В процессе подготовки утилит 3.0 мы пренебрегли добавлением функционала отображения переменных и сейчас настало самое время заняться этим вопросом.

Графический интерфейс диктует свои правила, с которыми приходится считаться. Если в утилитах 2.2, при выполнении команды, достаточно было параметром '--set' передать новое значение переменной, то в графическом интерфейсе такой подход уже явно не подходит. В итоге три идеи объединённые вместе зародили новый проект - ветку 3.1.

Первую идею подкинула новая возможность утилитой cl-core изменять значение переменных, записывая изменения в /etc/calculate/calculate3.env. cl-core работает на стороне сервера и такая возможность нужна была для отладки. Тем не менее, подобный подход отлично подходит для реализации изменений значения переменных. cl-core для указания метода использует запись вида метод.переменная, что также подтолкнуло на мысль использовать такую запись в шаблонах.

С момента перехода на утилиты 2.0, пакет calculate был разбит на несколько. Каждый пакет отличался своим набором переменных и своей логикой работы. В версии 2.2 мы выполнили объединение шаблонов в одну директорию templates. Все шаблоны в ней разделены по по древовидной структуре, в основе которой лежат директории с именами пакетов утилит. Если мы сможем обращаться сразу ко всем переменным утилит, то почему бы нам не переделать структуру портежей, взяв за основу события, а не методы. Подробнее про события можно почитать здесь.

Что мешало это сделать раньше?

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

Что изменится?

# Немного ускорится обработка шаблонов, т.к. вызов наложения шаблонов для изменения системных файлов не нужно будет производить отдельно для пакетов calculate-desktop и calculate-client.
# Расширится функционал Clt шаблонов. Теперь можно будет обращаться к любым переменным. В настоящее время Clt шаблоны могут использовать только переменные calculate-install.
# Новая структура дерева шаблонов выглядит более логичной и понятной. Во главу угла ставится событие, а не пакет.

Чтобы не переписывать шаблоны, добавляя к каждой переменной метод, будет добавлена поддержка указания метода на уровне не только переменной, но и заголовочного файла или директории, через опцию module. Т.е. достаточно указать ‘module=install’, чтобы для всех файлов внутри директории по-умолчанию работа была с переменными пакета calculate-install.

Так как новая система шаблонов не будет поддерживаться утилитами 3.0, решено было взять номер версии 3.1.

И напоследок самое интересное, возвращаясь к реализации изменения значений переменных. Такая поддержка появится и в консоли, и в графическом клиенте. Причём в последнем она будет чем-то напоминать изменение параметров в браузера firefox при вводе в адресной строке ‘about:config’. Изменённые значения будут сохраняться и использоваться при последующих запусках утилит.

Где можно посмотреть?

Лучше один раз увидеть. Обновите оверлей и перейдите в директорию шаблонов:

eix-sync
cd /var/lib/layman/calculate/profiles/templates/
ls -l

Это текущая система шаблонов. Перейдя в директорию ‘3.1’, вы увидите новую структуру шаблонов.

cd 3.1
ls -l

Easy Linux from the Source

В Calculate Console версии 3 есть одна проблемка, которой не было во второй версии. А именно часовой пояс. Пропали из настроек часовые пояса Прибалтики и других стран Евросоюза. Это так и должно быть?

Нет, я понимаю, что это всё можно настроить ручками, задав в консоли пару команд ( ln -sf /usr/share/zoneinfo/Europe/Tallinn /etc/localtime ). Но раньше эти настройки были, а теперь нет, почему? Ещё страннее, что в самом дистрибутиве есть все необходимые файлы, так почему они не отображаются?

Раньше при установке из iso я устанавливал Europe/Minsk (+03:00), а потом из console-install-gui находил часовой пояс для Эстонии и устанавливал его. Теперь утилиты абсолютно одинаковы и настроек часовых поясов для Прибалтики нет.

Добавлено:
И у меня вопрос появился, я установил себе локальное время через вышеприведённую команду. Не будет ли это как-то конфликтовать с настройками в Calculate Console? Так как там, в разделе “Локализации” до сих пор стоит Минск.

Оформите пожалуйста задачу в багтрекере.

меня другое интересует… в calculate утилитах третьей версии теперь нельзя, оказывается, менять настройки в основных файлах?

Шаблоны в 3-их утилитах почти не претерпели изменений. В частности шаблон настройки xdm остался прежним. Можете сравнить:

  • /var/lib/layman/calculate/profiles/templates/install-3.0/1live/xorg-server/conf.d/xdm
  • /var/lib/layman/calculate/profiles/templates/install/1live/xorg-server/conf.d/xdm

В заголовке указан только разделитель комментария, не указан формат, поэтому по умолчанию используется raw, который полностью переписывает файл. В любом случае, если Вы будете менять значение например DISPLAYMANAGER, оно будет возвращаться при обновлении пакета и выполнении dispatch-conf, либо при выполнении настройки системы.

Если у Вас значение меняется во время установки пакета, смотрите значение переменной cl_autoupdate_set:

grep cl_autoupdate_set /etc/calculate/calculate3.env

Шаблоны не только преднастраивают пакеты, но и позволяют пользователю контролировать вносимые изменения, модифицируя их. Например через Clt файлы шаблонов.

Не думаю, что это там… ведь настройки всё-таки меняются…
date показывает:
Пт. авг. 10 22:29:19 EEST 2012
то есть, настройки изменены и используются…

меня другое интересует… в calculate утилитах третьей версии теперь нельзя, оказывается, менять настройки в основных файлах?

например, если я сделал изменения в etc/conf.d/xdm, то через некоторое время изменения исчезнут, а настройки вернутся к значениям по умолчанию… там же, в том же файле рекомендуется изменять значения в шаблонах… я правильно всё понимаю?

и каков механизм? из шаблона заменяется стандартный конфиг или что?

В любом случае, если Вы будете менять значение например DISPLAYMANAGER, оно будет возвращаться при обновлении пакета и выполнении dispatch-conf, либо при выполнении настройки системы.

как всё сложно…
ладно, в других дистрибутивах были проблемы с gui-конфигураторами и конфиги заменялись или правились на основе настроек…

в кальке, оказывается, уже три уровня (шаблоны, настройка системы Calculate Console и эти самые конфигурационные файлы)… интересно, а можно дать один уровень? чтобы всё менялось в одном месте и без всяких проблем? или это очень сложно и невыполнимо?

я уже привык к изменениям простых конфигов (даже без документации, в интернете что-то можно найти), но вот эта автоматизация (без документации), она просто убивает… чтобы что-то изменить, надо знать что менять и что, каждый мелкий вопрос задавать разработчикам?

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

Вообще, идея 3.1-утилит шикарная, совместно с собственными шаблонами, дает широкие возможности по массовой настройке компов.
Но есть один неприятный момент - после перехода на calculate:3 утилиты, среди служб boot-уровня появилась служба calculate-core, и выжирает порядка 135MB памяти.

И что самое неприятное - почему-то свопиться она не хочет.
Проверяется очень просто - когда на машине с гигом рама открываются несколько тяжелых презенташек и ods файлов в либре - свопа кушается еще под полгига-гиг, и если при этом остановить службу calculate-core, останавливается она почти сразу, и появляется свободная память, в которую потихоньку “перетекает” своп.

В связи с этим просьба в предстоящих утилитах реализовать:

  • либо двухуровневую систему, подобно xinetd, чтоб легкий демон слушал порт, и в случае необходимости - вызывал тяжелый обработчик
  • либо отключать не используемые либы после обработки запроса(думаю, это должно решить “меньшей кровью” постоянную занятость памяти)

Понимаю, что подобные задачи требуют большой работы, по переделыванию кода, но все-же считаю подобную задачу оправданной.

PS
Кстати, по поводу самой службы и ее порта.
Во первых - предлагаю “слушаемый” интерфейс сделать параметром настраиваемым, и чтоб по дефолту слушался лишь localhost.
Во вторых - порт 8888, равно как 8080 или 8000 уж слишком часто используется всякими наколеночными fcgi серверами. Предлагаю как вариант сменить его на 51740

0xCa1c == 51740
И смысл “глубокий” у этого порта, и не повторяется

как всё сложно…
ладно, в других дистрибутивах были проблемы с gui-конфигураторами и конфиги заменялись или правились на основе настроек…

в кальке, оказывается, уже три уровня (шаблоны, настройка системы Calculate Console и эти самые конфигурационные файлы)… интересно, а можно дать один уровень? чтобы всё менялось в одном месте и без всяких проблем? или это очень сложно и невыполнимо?

я уже привык к изменениям простых конфигов (даже без документации, в интернете что-то можно найти), но вот эта автоматизация (без документации), она просто убивает… чтобы что-то изменить, надо знать что менять и что, каждый мелкий вопрос задавать разработчикам?

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

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

По поводу документации Вы правы. Причин тут три - лишь в последнее время начинает появляться интерес к работе шаблонов и соответственно к документации, постоянные изменения в работе утилит ну и банальная нехватка времени.

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

Но есть один неприятный момент - после перехода на calculate:3 утилиты, среди служб boot-уровня появилась служба calculate-core, и выжирает порядка 135MB памяти.

Будем смотреть, спасибо.

P.S. http://www.calculate-linux.ru/boards/16/topics/16735