Единое окно доступа к образовательным ресурсам

Десятая конференция разработчиков свободных программ: Тезисы докладов

Голосов: 0

В книге собраны тезисы докладов, одобренных Программным комитетом десятой конференции разработчиков свободных программ, которая прошла в городе Калуге 20-22 сентября 2013 года.

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
    Утреннее заседание (10.00–13.20)                                            41


    При портировании операции с пакетами шаблонные, это отфиль-
тровывание и замена зависимостей, а также отрывание/изменение оп-
ций configure и накладывание патчей в определенных последователь-
ностях. При желании это все естественным образом автоматизирует-
ся.
    В идеале можно было бы роботом генерировать десятками опти-
мизированные сборки, можно стабильных бранчей, под каждый дру-
жественный к Linux планшет, е-книжку или другое устройство - там
ресурсы скудные, и оптимизация будет цениться.
    даже под ix86 было бы интересно сделать оптимизированные сбор-
ки Сизифа и p7 под atom, где тоже ресурсы относительно скудные,
под i686, под athlon.
    Облачный кластер автоматизации рассчитан на сопровождение со-
тен тысяч пакетов. Однако, чтобы раскрыть этот потенциал, необхо-
дима команда хотя бы из нескольких человек.

Шабалин Алексей
Москва, Лаборатория Касперского
Проект:   Systemd http://www.freedesktop.org/wiki/Software/systemd

                        Systemd в ALTLinux

                               Аннотация
      Systemd является альтернативной системой инициализации Linux,
   вобравшей в себя достоинства класического System V init и более совре-
   менных launchd (Mac OS X), SMF (Solaris), Upstart (Ubuntu). В докладе
   пойдет речь об особенностях systemd в ALTLinux.

Историческая хроника
   Первые упоминания в Интернет об прототипе systemd появились
в конце апреля 2010г.:
     http://0pointer.de/blog/projects/systemd.html,
     http://www.opennet.ru/opennews/art.shtml?num=26447
     7 июля 2010г.      представлена первая версия (systemd-v1).
     Cентября 2010г., с systemd-v10,      начало добавления поддержки
     ALTLinux.


42                                                        21 сентября


       Февраль 2011г. патчи с поддержкой ALTLinux приняты в ап-
       стрим (systemd-v18)
       Январь 2012г.   в polkit-0.104 добавлена поддержка logind
       Апрель 2012г.   импортирован проект udev в systemd.
       Январь 2013г. удаление из systemd поддержки любых дистри-
       бутиво-специфичных конфигурационных файлов, systemd is
       now fully generic and distribution-agnostic. Systemd-v197

Сравнение систем нинциализации
   Детальное сравнение систем инициализации опубликовано 28 ап-
реля 2011 http://0pointer.de/blog/projects/why.html (перевод на
русский http://www.opennet.ru/opennews/art.shtml?num=30412)
   Рассматривайте это сравнение с большой долей скептицизма, т.к.
большинство параметров для сравнения решались не внутри самого
sysvinit, а внешними скриптами и настройками, что для конечного
пользователя не существенно.
   Стоит отметить следующие достоинства systemd:
     • Поддержка SysV init-скриптов, как свох собственных сервисов
     • Активация сервисов на основе сокетов: совместимость с inetd
     • Интеграция с Linux Control Groups, автоматически создаёт
       cgroups для сервисов и пользовательских процессов для рав-
       номерного распределения времени CPU
     • Поддержка контейнеров (как расширенная замена chroot())
     • Загрузка, построенная на основе зависимостей
     • Динамическая генерация сервисов
     • Файлы запуска сервисов, совместимые с различными дистрибу-
       тивами
     • Легкие для написания, расширения и обработки файлы управ-
       ления сервисами
     • Удобные средства диагностирования и анализа загрузки systemd-
       bootchart, systemd-analyze:
       # systemd-analyze time
       Startup finished in 5.810s(kernel)+16.161s(userspace)=21.971s
       # systemd-analyze blame


Утреннее заседание (10.00–13.20)                                 43


         7.392s sysstat.service
         7.332s ModemManager.service
         6.102s altlinux-update_chrooted.service
         4.707s lvm2-activation-net.service
         3.885s systemd-udev-settle.service
         2.183s NetworkManager.service
         1.359s systemd-fsck-root.service
         1.139s systemd-fsck@dev-disk-by\x2duuid-1dbbfa8d\x2d843c
                         \x2d4ad4\x2daa61\x2dab499b942872.service
          904ms syslogd.service
          826ms systemd-tmpfiles-clean.service
          784ms systemd-random-seed.service
          534ms var-run.mount
          448ms colord.service
          ......


Особенности systemd в ALTLinux

   • Systemd не единственная система инициализации в ALTLinux.
     В сервисах должна быть обеспечена поддержка SysV init скрип-
     тов.
   • chkconfig, service, post_service, preun_service адаптированы для
     прозрачной работы с systemd и SysV. Мантейнеру не нужно спе-
     циально использовать никаких новых макросов.
   • /usr может быть на отдельном разделе диска.
   • Изменены пути:
     rootbindir=$(rootprefix)/bin → rootbindir=$(rootprefix)/sbin
     /usr/lib/systemd → /lib/systemd
     /usr/lib/tmpfiles.d → /lib/tmpfiles.d
     /usr/lib/binfmt.d → /lib/binfmt.d
     /usr/lib/modules-load.d → /lib/modules-load.d
     /usr/lib/sysctl.d → /lib/sysctl.d

   • поддержка старых      ALTLinux-специфичных конфигурацион-
     ных файлов:
     /etc/sysconfig/i18n
     /etc/sysconfig/network (для определения hostname)
     /etc/sysconfig/keyboard и /etc/sysconfig/consolefont


44                                                         21 сентября


     • Для поддержки старого именования сетевых интерфейсов воз-
       вращена функция переименования в udev. Старая схема неиз-
       менности имен сетевых интерфейсов также поддерживается.
     • Для корректной локализации консоли сдвинут в конец инициа-
       лизации systemd-vconsole-setup.service
     • bash-completion адаптированы для bash3
     • Часть программ вынесены в отдельный пакет systemd-utils
       (systemd-tmpfiles, systemd-binfmt, systemd-modules-load, systemd-
       sysctl) и предложены для использования в SysV
     • Выключены сервисы, функции которых выполняются systemd
       (fbsetfont, keytable, killall, halt, single, netfs)

TODO
     • Максимально убрать ALTLinux-специфичные изменения.
     • Улучшение поддержки ALTLinux-специфичных настроек в
       /etc/sysconfig/ {consolefont,i18n,keyboard}. Перенос их обработ-
       ки в генератор.
     • Появление bash4 в ALTLinux сильно облегчит поддержку bash-
       completion.
     • Отказ от prefdm. Замена на gdm.service, kdm.service, и т.п.
     • systemd в initrd
     • Генератор для cron ?
     • Генератор для xined ?
          Выдержка из беседы Линуса Торвальдса со сту-
       дентами университета Аалто (23.12.2012):
       Ок. Вопрос был о моем мнении на счет Systemd и о том,
       как некоторые люди думают, что она ломает философию
       unix и что она просто другая. Я не знаю скольких людей
       здесь волнует, что Systemd это такая замена традицион-
       ной модели Init. И она, в общем, пытается взять на себя
       множество других вещей в процессе запуска. Мне, на са-
       мом деле, нравится многое из того, что делает Systemd.
       Лично моя самая большая проблема с Systemd это то,


Дневное заседание (14.50–18.10)                                            45


     что многие вовлеченные люди похоже думают, что из-
     менение     это хорошо само по себе. Я видел, как Лен-
     нарт Поттеринг(разработчик Systemd), например, гово-
     рил о том что что-то сделано плохо, потому что это
     что-то делалось 30 лет и все это    плохое по определе-
     нию. Что для меня не имеет никакого смысла, потому
     что я думаю, если это работало 30 лет, оно определенно
     делает что-то правильно. Это моя точка зрения. В то
     время как некоторые люди из команды Systemd, похоже,
     имеют строго противоположные желания, говоря, что
     если оно работало таким образом 30 лет, то самое вре-
     мя это изменить. И такой склад ума заставляет меня
     очень нервничать, похоже, что иногда они делают изме-
     нения ради изменений и не сильно беспокоятся о том к
     чему люди привыкли и приспособились. . . Это, вероятно,
     причина почему Systemd генерирует столько негативных
     отзывов, потому что она выбивает людей из ощущения
     комфорта и чувствует себя неплохо по этому поводу. И
     в то же время я думаю, что многое, что она делает
     интересно. Так что я немного нервничаю по поводу мо-
     дели разработки и желания ломать вещи, что я считаю
     огромной ошибкой, но я также думаю, что она показы-
     вает множество перспектив.


Михаил Владимирович Быков
Москва, http://diglossa.ru
Проект: grunt-couch-mocha
https://github.com/mbykov/grunt-couch-mocha


Простой стек технологий для BDD-style разработки
                SPA на coffeescript


                                Аннотация
       Как развернуть среду BDD-style разработки Single Page Application
   за 10 мин? Оказывается, можно. Вот этот нужный нам стек: node,
   grunt, coffeescript, mocha, phantom, couch


46                                                                  21 сентября


Пререквизиты
  Предполагается, что вам известны и у вас установлены Node.js,
npm, CouchDB.
     − sudo apt−g e t i n s t a l l node npm
     − sudo apt−g e t i n s t a l l couchdb
     − rtfm

     Клонируйте полный пример:
g i t c l o n e h t t p s : / / g i t h u b . com/mbykov/ grunt−couch−mocha .

   Все используемые npm-модули следует устанавливать в корне на-
шего проекта без ключа -g (если не сказано обратное явно), и удобно
клонировать сам модуль по соседству, потому что обычно в нем есть
примеры, которые существенно проясняют документацию.

SPA
   Значение приложений, целиком работающих в браузере, растет
очень быстро. Загрузки соответствующих модулей на npmjs.org из-
меряются тысячами в день, посмотрите, например, bower        8 тыс
установок в день. Меня особенно интересуют SPA         Single Page
Application. Т.е приложения, которые при клике по линку не перегру-
жают страницу целиком, но лишь подгружают необходимые данные.
Однако настроить рабочую среду для разработки SPA и организо-
вать код Javascript модульно и пригодно для тестирования считается
сложной задачей.

AMD vs. CommonJS
   Прежде всего, код должен быть разбит на маленькие модули, каж-
дый из которых выполняет свою задачу (знакомая тема). Модулей в
JS сейчас (до v.6) существую два типа AMD (Asynchronous Module
Definition)    и CommonJS. Второй не позволяет подгружать модули
асинхронно. Но зато он является основой работы node.js. На основе
AMD построены Yeoman и Bower, см http://yeoman.io чрезвычайно
популярная технология. Йомен решает именно ту задачу, которая бы-
ла вынесена в заголовок настоящего доклада. Но это бегемот, устанав-
ливая среду разработки, он устанавливает десятки и м.б. сотни npm-


Дневное заседание (14.50–18.10)                                                 47


модулей сплошным потоком. И в случае возникновения ошибки или
сбоя найти концы будет невозможно, или по кр.м. этот процесс съест
ровно то время, которое вы сэкономите, если воспользуетесь Йоме-
ном. Я собираюсь за 10 минут сделать то же самое что делает Йомен,
но пошагово, вручную и на основе стандартного CommonJS. Потому
что AMD выглядит уродливо, а смысл в асинхронной загрузке мо-
дулей неясен   все равно, пока все необходимое не будет загружено,
приложение не стартует.

Grunt
   Grunt это инструмент подобный Make, Rake, Cake etc. См http:
//gruntjs.com. Итак, создаем наш проект conf:
     $   mkdir c o n f && cd c o n f
     $   npm i n i t
     $   sudo npm i n s t a l l −g grunt− c l i
     $   grunt−i n i t commonjs

   Здесь мы создаем npm-описание проекта, т.е. файл package.json.
Затем устанавливаем grunt-cli и выполняем grunt-init, который созда-
ет для нас центр всего проекта, файл Gruntfile.js, в котором пока что
много лишнего, уберите все. Вот нужный минимум, можно просто его
скопировать:
/∗ g l o b a l module : f a l s e ∗/
module . e x p o r t s = f u n c t i o n ( g r u n t ) {
   // P r o j e c t c o n f i g u r a t i o n .
   grunt . i n i t C o n f i g ({
       // Task c o n f i g u r a t i o n .
   }) ;
   // D e f a u l t t a s k .
   g r u n t . r e g i s t e r T a s k ( ’ d e f a u l t ’ , [ ’ xxxx ’ ] ) ;
};


CouchDB
   CouchDB это документо-ориентированная БД, но с другой сто-
роны, это скорее философия. Доступ к ней осуществляется по про-
токолу http://, данные внутри хранятся в json, основной используе-
мый язык javascript (но можно использовать что угодно также), и


48                                                                      21 сентября


можно использовать все тот же стандарт CommonJS. Таким образом,
CouchDB сам себе веб-вервер. Приложения, построенные на основе
кауча, называются couchapp.
   Найдите на сайте npmjs.org модуль grunt-couch и установите его:
$ npm i n s t a l l grunt−couch −−save−dev

   Здесь --save-dep для того, чтобы зависимость сама прописалась
в файле package.json, это удобно. Но мне привычннее создать дирек-
торию ddoc (от слов design-document), и скопировать файлы grunt-
couch/test/fixtures/full в нее, получится что-то вроде:
_a t t a c h m e n t s /
|−− t e m p l a t e s
|−− t e s t
 | |−− c s s
 | |−− s p e c
 | |−− j s
|−− c s s
|−− j s
 | |−−vendor
|−− i n d e x . html
 filters/
_i d
language
 lists/
 rewrites . json
shows /
updates /
 v a l i d a t e_doc_update . j s
views /

   В файле Gruntfile.js добавляем две задачи, couch-compile и couch-
push, и регистрируем модуль кауч:
     grunt . i n i t C o n f i g ({
       // Task c o n f i g u r a t i o n .
         ’ couch−compile ’ : {
                 app : {
                         files : {
                                 ’ tmp/ ddoc . j s o n ’ :   ’ ddoc ’
                        }
                 }


Дневное заседание (14.50–18.10)                                                                    49


         },
         ’ couch−push ’ : {
                 options : {
                        u s e r : ’ admin ’ ,
                        pass : ’ k j r e 4317 ’
                 },
                 localhost : {
                        files : {
                                ’ h t t p : / / l o c a l h o s t : 5 9 8 4 / myapp ’ :   ’ tmp/
                                       ddoc . j s o n ’
                        }
                }
         },
         .....
         g r u n t . loadNpmTasks ( ’ grunt−couch ’ ) ;

   Мне обычно удобно прописать в файле /etc/hosts локальный хост
  $ cat / etc / hosts
  ....
  127.0.0.1           couch . l o c

   и прописать его в файле настроек Кауча:
  $ sudo c a t / u s r / l o c a l / e t c / couchdb / l o c a l . i n i | g r e p
      couch . l o c


[ vhosts ]
   ; example . com = / d a t a b a s e /
   ...
   couch . l o c : 5 9 8 4 = /myapp/_ d e s i g n / f u l l /_ r e w r i t e /

   Выполняем команды
$ g r u n t couch−c o m p i l e
$ g r u n t couch−push

   Можно создать задачу "couch объединяющие эти две:
   grunt.registerTask(’couch’, [’couch-compile’, ’couch-push’]);
   и теперь можно посмотреть на вновь созданную базу conference
в Футоне по адресу http://localhost:5984/_utils/, и собственно
работающее приложение http://couch.loc:5984/


50                                                                    21 сентября


Mocha / PhantomJS
   Самое главное: на nodejs.org находим, клонируем и устанавливаем
модули
$ npm i n s t a l l grunt−mocha
$ npm i n s t a l l grunt−mocha−phantomjs −−save−dev

   Скопируйте файлы из директории grunt-mocha/example/test/ в
ddoc/_attachments по образцу.
   Пропишите задачи mocha и mocha_phantomjs в файле Gruntfile.js
  см. пример.
   Вместо Mocha точно так же можно установить Jasmine, вместо
PhantonJS ZombieJS. Фантом использует реальный движок webkit,
а Зомби   абстрактную реализацию HTML5 и CSS3, но он гораздо
быстрее.
   В файле, который мы вызываем в тесте, сейчас ddoc/_attachments/
test/test.html, нужно указать
i f ( window . mochaPhantomJS ) { mochaPhantomJS . run ( ) ; }
e l s e { mocha . run ( ) ; }

   это не сказано в документации к grunt-mocha, но если исполь-
зовать grunt-mocha-phantomjs, работает именно именно этот вызов
функции mocha.run(). Собственно, это и есть единственная хитрость
всего процесса.
   Теперь мы можем видеть, как выполняются наши тесты в браузере
  http://couch.loc:5984/test/test.html, и в консоли:
  Wombat
       s h o u l d c r e a t e a wombat with d e f a u l t s
       s h o u l d name i t s e l f i f name p a s s e d i n o p t i o n s
   #e a t
           s h o u l d throw i f no f o o d p a s s e d
           s h o u l d r e t u r n noms i f f o o d p a s s e d

     Apple
          s h o u l d go crunch


     5 t e s t s c o m p l e t e ( 2 4 3 ms)



    
Яндекс цитирования Яндекс.Метрика