Статьи

Настраиваем VPN Магинфо средствами NetworkManager

vyazovoi — Wed, 29 Jun 2011 15:13:29 +0400

Итак, в мои руки наконец-то попала система с установленным NetworkManager и pptp-плагином с необходимостью настройки на ней vpn Магинфо.

Внимание: для работы нижеописанного у вас в системе должен быть установлен NetworkManager, pptp + плагин для NetworkManager для работы с pptp. Об этом вам придется позаботиться самим. Скажу только что в попавшей в мои руки Fedora Russian remix DVD все это есть.
Инструкции по установке для других дистрибутивов можно писать в комментарии к статье.

Как я и говорил - делается это предельно просто:

1) Нужно поправить текущее подключение по сети (я создал новое, но можно просто исправить то, что подключается по умолчанию). А именно в нем нужно прописать дополнительные маршруты:

2) Создаем VPN-соединение с настройками по умолчанию (я только ставлю галочку в "Advanced" на mppe для шифрования, но и без нее с настройками полностью по умолчанию должно работать). Не забываем только прописать сервер, логин и пароль (можно ещё поставить галочку "подключать автоматически"):

Материалы семинара 19.03

portnov — Tue, 22 Mar 2011 17:01:50 +0300

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

Лицензия — CC BY SA 3.0.

1. А. Бармин. «Управление требованиями к IT-проектам в OSRMT»:	Презентация	Запись выступления
2. А. Новикова: Багтрекер Mantis:		Запись выступления
3. Е. Ерошин «JavaScript-фреймворк jQuery»:		Запись выступленпия
4. И. Портнов: "Использование asciidoc и docbook для подготовки технической документации":	Презентация, текст доклада	Запись выступления
5. М. Сорокин: «Автоматизация рутинной работы с помощью ant,izpack,hudson»:	Презентация	Запись выступления
6. Г. Канин: "Нюансы проектирования в OpenOffice.org Base":	Презентация	Запись выступления
7. И. Попова «Система управления бизнес-процессами Activiti BPM 5.3»:	Презентация	Запись выступления

См. также фотоальбом.

Настройка VPN от Магинфо на роутере DLink DIR-300 rev.B1 с прошивкой DD-WRT

portnov — Mon, 10 Jan 2011 09:38:08 +0300

Родная прошивка у распространённого в наших краях WiFi-роутера (точки доступа) DLink DIR-300 весьма глючная, так что многие предпочитают заменить её на прошивку DD-WRT. Только вот в настройке VPN от Магинфо в DD-WRT есть пара неочевидных моментов.

Важно. Речь здесь идёт только об одной конкретной модели устройства — «DLink DIR-300», причём именно в ревизии B1.

Установка DD-WRT на этот роутер описана, например, здесь. Настройка VPN от Магинфо на другой модели роутера DLink описана здесь (доступно только из сети Магинфо).

Предупреждение. Последняя имеющаяся сейчас на dd-wrt.com версия прошивки (14896) содержит кривой pptp-клиент, при запуске он вываливается с Segmentation Fault. Так что эту версию скачивать не надо, берём предыдущую (14311) или следующую, когда эти следующие версии появятся.

Настройка VPN в dd-wrt включает следующие шаги:

Прописать общие настройки VPN (адрес сервера, логин, пароль итп);
Добавить нужные записи в таблицу роутинга;
Удалить одну ненужную, но появляющуюся по умолчанию запись из таблицы роутинга;
Прописать в конфигурационный файл pptp пару неочевидных опций, специфичных для Магинфо.

Общие настройки

В веб-интерфейсе роутера идём на вкладку «Services | VPN», там ставим переключатель «PPTP Client Options» в положение «Enable», и прописываем остальные опции:

Server IP or DNS Name.: Адрес VPN-сервера. У нас это vpn.mgn.ru.
Remote Subnet, Remote Subnet Mask.: Оставляем по умолчанию (0.0.0.0).
MPPE Encryption.: Параметры шифрования MPPE. В упомянутой выше статье на wiki.mgn.ru предлагается сюда вписать «mppe required,no40,no56,stateless».
MTU, MRU.: Похоже, оптимальные значения зависят от конкретных роутеров, находящихся между вами и VPN-сервером. Я сейчас выставляю 1500, работает. Когда-то приходилось выставлять 1300, чтобы добиться нормальной работы сети. Замечание. Веб-интерфейс сильно умный и, согласно стандартам, не даёт выставлять здесь значения больше 1500. Между тем, при некоторых условиях может понадобиться указать MTU и MRU равными 1512 (разъяснено, например, здесь).
NAT.: Оставляем по умолчанию (Enable).
User Name, Password.: Логин и пароль вашего VPN-соединения.

Ну и жмём Save. Пытаться делать Apply сейчас бесполезно, всё равно не заработает.

Добавляем нужные роуты

В веб-интерфейсе идём на вкладку «Setup | Advanced Routing» и добавляем следующие роуты:

79.134.0.0 netmask 255.255.255.252 gw YOUR_GATEWAY.
192.168.55.32 netmask 255.255.255.224 gw YOUR_GATEWAY;

Здесь YOUR_GATEWAY — это IP вашего шлюза. В параметре «Interface» для обоих роутов выставляем «WAN», метрику оставляем 0.

Немного плясок с бубном

В веб-интерфейсе роутера идём на вкладку «Administration | Commands», и в качестве Startup-комманд вписываем следующее заклинание:

(while [ ! -f /tmp/pptpd_client/options.vpn ]; do sleep 10; done route del default dev vlan2 sed -e 's/lcp-echo-failure 3/lcp-echo-failure 5/' -e 's/lcp-echo-interval 2/lcp-echo-interval 30/' /tmp/pptpd_client/options.vpn > /tmp/pptpd_client/temp.vpn cp /tmp/pptpd_client/temp.vpn /tmp/pptpd_client/options.vpn )&

Здесь происходит следующее. При запуске роутера ждём, пока появится файл /tmp/pptpd_client/options.vpn (это актуальный конфиг pptp, формируемый скриптом на основе шаблона, лежащего где-то в /etc). Когда он появился — это означает, что pptp-клиент вот-вот запустится. В этот момент удаляем дефолтный маршрут через ваш шлюз (правда, это можно делать и в самом начале скрипта) и с помощью sed-а правим конфиг pptp, а именно, указываем там опции lcp-echo-failure 5 и lcp-echo-interval 30.

Такой неочевидный способ сделать вроде бы простые вещи (удалить маршрут и поправить пару строчек в конфиге) вызван тем, что 1) в веб-интерфейсе не предусмотрено способа удалить маршрут, можно только добавить, 2) в веб-интерфейс вынесены далеко не все настройки pptp-клиента, при этом 3) шаблонный конфиг pptp находится на read-only файловой системе, а актуальный формируется только при запуске.

Ну и после сохранения настроек перезагружаем роутер, теперь всё должно работать.

Если кто-нибудь предложит способ сделать всё то же самое прямее, буду очень благода.

Настройка интернета Магинфо в BSD

vyazovoi — Thu, 14 Oct 2010 18:45:20 +0400

Инструкция для BSD: (Паша, добавь)
Всё просто, настраивается через /etc/hostname.xxx, где xxx - имя интерфейса

#ifconfig - смотрим как наз-ся наши интерфейсы
обычно: rl0 - Realtek8139, re0 - Realtek8169, xl0 - 3c905(возможно, и другие 3Com)

Сначала настраиваем опорную сеть:

root@bsd:~# cat /etc/hostname.rl0
inet 192.168.xxx.yyy 255.255.255.0
!route delete -inet 79.134.0.0/30
!route delete -inet 192.168.55.32/27
!route add -inet 79.134.0.0/30 192.168.xxx.1
!route add -inet 192.168.55.32/27 192.168.xxx.1

Где xxx - подсеть, yyy - хост
Можно просто написать:
inet dhcp
Но в этом случае я не знаю как поднять статические маршруты до DNS & VPN

Далее, настраиваем интерфейс для VPN:

root@bsd:~# cat /etc/hostname.tun0
!/usr/sbin/ppp -unit0 -ddial mgn >/dev/null 2>&1

Где mgn - название нашего провайдера, см.ниже. Может быть любым(разумным).
unit0 задает что интерфейс поднимется именно tun0 - актуально для файрвола

Теперь самая сложная часть, собсно конфиг PPP:

root@bsd:~# cat /etc/ppp/ppp.conf
default:
 set log Phase Chat LCP IPCP CCP tun command

mgn:
 set device "!/usr/local/sbin/pptp --loglevel 0 --nobuffer --nolaunchpppd vpn.mgn.ru"
 set timeout 0
 set lqrperiod 15
 set cd 5
 set redial 5
 set authname ВАШ_VPN_ЛОГИН
 set authkey ВАШ_VPN_ПАРОЛЬ
 set dial
 set login
 set mppe 128 stateless
 accept MSChapV2
 enable lqr
# enable mssfixup
 disable acfcomp protocomp
 disable ipv6cp
 deny acfcomp
# set mtu max 1462
# set mru max 1462
 add! default HISADDR

С такими mtu/mru у меня не ходили большие пакеты, потому закомментил.
Обратите ОСОБОЕ внимание на строку authkey - пароль хранится в конфиге!!!
Перед тем как показывать свой конфиг кому-то, не забудьте удалить/заменить пароль)
Обязательно выполните команды:
#chown 0.0 /etc/ppp/ppp.conf
#chmod 400 /etc/ppp/ppp.conf - так будет безопаснее.
Во всяком случае vi так просто его не перезапишет - ругнется: Read-only file, not written; use ! to override.

#sh /etc/netstart - (пере)запуск всех интерфейсов

Один важный момент. Пакета pptp на свежепоставленной машине может не быть. Его придется скачать предварительно.
Текущие:
ftp://mirror.corbina.net/pub/OpenBSD/4.7/packages/i386/pptp-1.7.2p1.tgz
ftp://mirror.corbina.net/pub/OpenBSD/4.7/packages/amd64/pptp-1.7.2p1.tgz
Для NetBSD чет ваще пакетов не нашел... В-общем ищите сами) Втч для FreeBSD
Устанавливаем при помощи команды:
pkg_add pptp - в текущем каталоге должен сам найти нужную версию, но точно уже не помню

На будущее рекомендую прописать в ~/.profile
export PKG_PATH=ftp://mirror.corbina.net/pub/OpenBSD/4.7/packages/`machine -a`/

На этом пока всё. О настройке PF(PacketFilter) в следующий раз)

ЗЫ Если после поднятия сети не пингуется vpn.mgn.ru - проверьте свой /etc/resolv.conf

root@bsd:~# cat /etc/resolv.conf
lookup file bind
search mgn.ru vpn.mgn.ru ll.mgn.ru
nameserver 79.134.0.1
nameserver 79.134.0.2

Настройка интернета Магинфо в Linux v.2

vyazovoi — Tue, 22 Jun 2010 21:40:07 +0400

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

Редактировать буду по мере накопления информации

Настройка интернета магинфо в Linux

Настройка через NetworkManager в Ubuntu 10.04+, Fedora Russian remix и других дистрибутивах (другие не проверял)

Настройка описана здесь: lug-mgn.ru/…

Старый способ - правка конфигурации pptp

Во-первых, для подключения вам понадобится pptp-клиент. Скорее всего он уже есть в вашем дистрибутиве, убедиться в его наличии можно: необходимо открыть терминал и ввести pptp, если выйдет несколько строк типа “pptp version 1.7.2” и т.д. - он у вас есть. Иначе вылетит что-нибудь типа “нет такого файла”, “неверная комманда”, “command not found”, “no such file or directory” и т.п.

Если у вас не оказалось pptp и вы не можете установить его средствами дистрибутива, т.к. вы ещё не настроили интернет - постарайтесь скачать пакет вручную на сайте дистрибутива и установить. Пакет должен называться pptp, pptp-linux или pptp-client, но может называться и по другому. Например, вот несколько адресов:

Ubuntu: http://packages.ubuntu.com/search?keywords=pptp-linux
Debian: http://packages.debian.org/search?keywords=pptp-linux
Archlinux: http://www.archlinux.org/packages/pptpclient

Теперь процесс настройки по шагам:

1) Необходимо отредактировать конфиг pptp (все действия производятся в окне терминала):

Предположим, что вы имеете настроенную средствами дистрибутива локальную сеть (т.е. ping vpn.mgn.ru даёт положительный результат)
Делаем резервную копию файла /etc/ppp/options: sudo cp /etc/ppp/options /etc/ppp/options.backup
Открываем конфиг на запись: sudo nano /etc/ppp/options
Пишем в него следующее (поменяйте ВАШ-VPN-ЛОГИН на свой vpn-логин):


local
lock
detach
persist
maxfail 10

mtu 1512
mru 1512

require-mppe-40
require-mppe-8
require-mppe

lcp-echo-interval 30
lcp-echo-failure 5

require-mschap-v2
refuse-pap
refuse-chap
refuse-mschap
refuse-eap

defaultroute

user ВАШ-VPN-ЛОГИН
noauth

Сохраняем и выходим из редактора nano (Ctrl+o затем Ctrl+x)

2) Теперь необходимо отредактировать файл /etc/ppp/chap-secrets, пишем туда:


ВАШ_VPN-ЛОГИН * ВАШ_ПАРОЛЬ *

Сохраняем. Далее в консоли выполняем:

sudo chmod 400 /etc/ppp/chap-secrets

3) Теперь завершающий шаг: при каждом подключении необходимо поднимать маршруты до впн-сервера и днс-серверов и запускать pptp-клиент. Мы запишем все эти действия в простейший скрипт, при запуске которого будет подниматься интернет. Этого вам хватит для того, чтобы выйти в интернет и начать осваивать linux в поисках более адекватного решения. Думаю самое адекватное решение - настройка через Network Manager (описана в начале статьи).

Итак, открываем редактор: nano ~/vpn.sh и пишем следующее:


sudo /sbin/route del default
sudo /sbin/route add -net 192.168.55.32 netmask 255.255.255.224 gw <ваш_шлюз>
sudo /sbin/route add -net 79.134.0.0 netmask 255.255.255.252 gw <ваш_шлюз>
# для 100-мбит локалки
sudo /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw <ваш_шлюз>
sudo /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw <ваш_шлюз>
sudo pptp vpn.mgn.ru

Не забудьте заменить <ваш_шлюз> на адрес вашего основного шлюза. Его можно узнать у техподдержки провайдера, или, если вы знаете свой ip-адрес, заменив в этом адресе цифры после третьей точки на единицу.

Теперь необходимо дать скрипту права на выполнение:

chmod +x ~/vpn.sh

Запускать интернет следующей коммандой:

~/vpn.sh

Примечание для старых дистрибутивов: в старых ядрах (не скажу точно до какой версии) поддержка шифрования (MPPE) для ppp была отдельным модулем (а когда-то вообще требовалось накладывать патчи). Так что можно попробовать сделать find /lib/modules -name “*mppe*” и подгрузить найденный модуль. Пользователям более-менее современных дистрибутивов - не забивайте голову, примечание не для вас.

P.S. Может быть ещё для BSD-семейства описать процесс кто-то сможет?

P.P.S Опечатки и ошибки пишите в комментариях, или мне лично в конференции lug-mgn@conference.jabber.ru - буду править.

Документирование PHP-кода

vyazovoi — Sun, 14 Mar 2010 19:24:02 +0300

Извините за кривое форматирование, некогда править. Рекомендую смотреть красивый документ здесь: http://vyazovoi.github.com/pages/phpdoc.html
Слайды в pdf брать здесь: http://vyazovoi.github.com/files/phpdoc.pdf

1 Введение

2 phpdoc
- 2.1 Теги
- 2.2 Пакеты

3 phpDocumentor

4 Doxygen

5 Сравнение

1 Введение

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

Для удобства программистов существуют специальные комментарии, которые служат для автоматической генерации документации.

Хороший пример правильного комментария - это комментарий, содержащий:

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

Назначение описываемого кода.

Описание возвращаемого значения и входных параметров функции - в имени переменной много информации не уместишь.

Любая другая полезная информация

2 phpdoc

Начнем с теории:

Генератор документации - это программа, которая анализирует исходный код и генерирует
документацию для программистов или для пользователей с такими удобствами как поиск и
глоссарий.

Для того, чтобы анализатор мог считывать дополнительную информацию, нужен стандарт на
документирующие комментарии. Также интегрированные среды разработки могут использовать
такие комментарии для, например, вывода всплывающих подсказок.

Первым стоит упомянуть phpdoc - это адаптация javadoc под php. Написан на
PHP. Популярностью не пользуется, тем не менее его формат комментариев стал стандартом де-факто
для документирования php-кода.

Блок с комментарием называется DocBlock. Вот примеры DocBlock'ов:

Слайд №1

Первый докблок в файле - комментарий для всего файла.

Базовые элементы любого док-блока это короткое описание, развернутое
описание и теги.
Длинное описание отделяется от короткого пустой строкой или точкой.
Развернутое описание может содержать в себе html-форматирование.

2.1 Теги

Слайд №2

Теги это специальные ключевые слова, которые начинаются с символа "собака". Все теги
являются опциональными.

2.2 Пакеты

Пакеты обозначаются тегом "@package". Пакеты объединяют константы, переменные, функции и классы
в группы. Если взять в пример сам PHP - каждый его подключаемый модуль может быть отдельным пакетом.

На этом месте мы закончим с теорией и перейдем к генераторам документации.

3 phpDocumentor

Слайд №3

phpDocumentor является стандартом де-факто для документирования PHP-кода. Как
результат - он поддерживается в большинстве PHP-ориентированных сред разработки, например, в популярном
Zend Studio. Более того, Zend Studio работает корректно только с DocBlock'ами
phpDocumentor.

Надо отметить, что phpDocumentor пока не поддерживает нововведения недавнего PHP версии 5.3.

Что касается кроссплатформенности: т.к. phpDocumentor написан на PHP - он работает везде, где работает PHP.

4 Doxygen

Слайд №4

Первое, что бросается в глаза - большое количество поддерживаемых языков.
Doxygen очень популярен и используется во многих opensource проектах. Среди них такие
проекты как KDE и Mozilla. Из известных PHP-приложений, которые используют Doxygen,
стоит упомянуть Drupal.
Doxygen также поддерживается многими средами разработки. Например Kdevelop и Eclipse (с
помощью стороннего плагина). Но среды, завязанные на PHP, предпочитают phpDocumentor.

5 Сравнение

Слайд №5

Есть у doxygen очевидные плюсы: поддержка нескольких языков и диаграммы связей.

Тем не менее, есть в нем и жирный минус, который я не упомянул ранее: не полная
поддержка PHP, связанная с тем, что doxygen ориентирован на язык си.

Author: Pavel Vyazovoi
<vyazovoi@googlemail.com>

Date: 2010-03-14 21:00:40 YEKT

HTML generated by org-mode 6.34c in emacs 23

Материалы доклада "Open source OLAP-система Jedox Palo BI Suite"

DropC — Wed, 10 Mar 2010 17:37:42 +0300

Публикую материалы доклада "Open source OLAP-система Jedox Palo BI Suite":
1. текст доклада в pdf
2. презентация в pdf

MyPaint. Обзор и What's new

portnov — Sat, 06 Mar 2010 18:43:49 +0300

Это конспект для доклада; Полноценный обзор MyPaint 0.8.0 можно найти здесь

Обзор

Как несложно догадаться из названия, MyPaint (http://mypaint.intilinux.com) - это программа для рисования (дословно - что-то вроде "моя живопись"; исторически, это название - ссылка на программу paint.exe от microsoft). Программ для рисования сейчас довольно много, в том числе и свободных, и под Linux (конечно, в первую очередь на ум приходит Gimp). Особенность MyPaint - это программа в первую очередь именно для рисования, а не для обработки готовых изображений (собственно, MyPaint даже не умеет таких вещей, как "кроп" или "уровни"; за такими функциями добро пожаловать в тот же Gimp). На самом деле, ближайшие конкуренты MyPaint - это Corel Painter и ArtRage.

Главным отличием программ этого класса от программ класса Gimp или Photoshop является максимально полная поддержка соответствующего "рисовального" оборудования (в первую очередь, планшетов) и мощный движок кистей. Например, Corel Painter имеет несколько встроенных алгоритмов расчёта ("акварель", "масло" итп), у каждого из алгоритмов есть некоторое количество параметров (размер кисти, степень размазывания, степень стекания краски итп), и каждый из параметров можно сделать зависимым от любых входных параметров (сила нажатия, направление движения, скорость итд). Каждый из алгоритмов кистей Corel Painter старается максимально полно имитировать физику соответствующего процесса (растекание акварели по бумаге, например). Это требует немалых вычислительных ресурсов, на машине четырёхлетней давности его запускать смысла не имеет.

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

Все кисти, доступные в MyPaint, являются, на самом деле, вариантами одной кисти (так как расчитываются по одному алгоритму), просто с разными настройками. Кисть имеет, на настоящий момент, 35 параметров (размер, степень непрозрачности и мн.др.). Каждый из параметров кисти может зависеть от любого набора из 8 входных параметров (сила нажатия, направление движения, скорость, случайный параметр итп). Причём, зависимость может быть как линейной (например, можно указать, что размер кисти равен 0.9 умножить на силу нажатия), так и нелинейной (можно задать любой график зависимости). Это порождает огромное количество вариантов кистей, которые, на первый взгляд, совершенно непохожи друг на друга. В комплекте MyPaint поставляется порядка двухсот кистей.

Над MyPaint работает довольно мало разработчиков. Начал разработку швейцарец Martin Renold. Сейчас над программой также работают норвежец Jon Norbdy, швейцарец Jonas Wagner и ваш покорный слуга. Кроме того, перевод на французский и китайский языки выполнил француз Oliver Gonduin, ну и т.д., всех уж перечислять не стану. Коллектив, как видим, интернациональный.

Что нового

Я сделаю небольшой обзор изменений, появившихся в дереве разработки MyPaint со времени выхода предыдущей версии - 0.7.1.

Интернационализация

MyPaint теперь может быть переведена на любой язык, с использованием инфраструктуры gettext. Я сделал перевод на русский. Уже есть переводы на французский, норвежский, шведский, немецкий и упрощённый китайский.

Палитра

Эта функциональность основана на работе Jon Norbdy, но я переписал практически весь код. Многие графические программы имеют ту или иную реализацию палитры - возможности запоминать наиболее часто используемые цвета. Однако текущая реализация палитры в MyPaint уникальна. Этот инструмент позволяет не только запоминать цвета, но и создавать новые. Палитра представляет собой прямоугольную таблицу из ячеек, каждая из которых может хранить цвет. Пользователь может "положить цвет" в некоторые из ячеек, а остальные ячейки будут заполнены автоматически, по принципу "растяжки". Например, если положить в одну ячейку красный цвет, в другую - жёлтый, то ячейки между ними будут заполнены плавным переходом от красного через оранжевый к жёлтому. Палитру можно организовывать в виде именованных групп (например, "оранжевые цвета" или "цвета для неба"). Палитра сохраняется между сеансами работы и, кроме того, она автоматически сохраняется в рабочий файл при сохранении в формат по умолчанию - OpenRaster.

Диалог слоёв

MyPaint поддерживает концепцию слоёв, аналогичную реализаци Gimp или Photoshop, начиная с версии 0.5.0. Однако, до сих пор управление слоями было довольно неудобным - например, переключиться на другой слой можно было либо через меню, либо по горячей клавише. Теперь в MyPaint есть диалог слоёв, более-менее похожий на диалог слоёв в Gimp или Photoshop. Можно перетаскивать слои, переименовывать их, устанавливать степень непрозрачности… Режимы слоёв в основном дереве разработки пока не поддерживаются, но работа над ними идёт вовсю.

Группы кистей

Как я уже упоминал, в MyPaint обычным делом являются сотни различных кистей. До сих пор MyPaint имел только один способ упорядочивать их - кисти можно было перетаскивать вверх-вниз в списке. Теперь кисти можно организовывать в группы. Каждая кисть может принадлежать сразу к нескольким группам (таким образом, на самом деле более точным термином здесь является "тег", а не "группа"). Кроме того, диалог выбора кисти теперь показывает несколько кистей, использовавшихся последними.

Поддержка наклона пера

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

Подбор цвета

В MyPaint к версии 0.7.1 уже было несколько способов выбрать цвет. Сюда относятся стандартный диалог выбора цвета, предоставляемый Gtk+, "цветовое колесо", и "пипетка", позволяющая взять цвет с холста. Теперь в MyPaint есть ещё один способ выбора цвета, называемый в английской версии Color Sampler. В основе его - цветовой круг для выбора оттенка и квадрат для выбора светлоты и насыщенности. Кроме того, внутри цветового круга показываются 12 ячеек с цветами, отличающимися только оттенком (светлота и насыщенность совпадают с выбранным цветом). Это простой инструмент, подсказывающий простые цветовые гармонии. В настройках инструмента можно попросить подсвечивать самые стандартные из гармоний - например, три цвета, расположенные на цветовом круге в вершинах равностороннего треугольника. Этот же инструмент может добавлять в палитру наборы цветов, основанные на выбранных гармониях.

Использование в Durian

Сейчас Blender Foundation ведёт работу над очередным "свободным мультфильмом" из серии Elephants Dream и Big Buck Bunny. Кодовое название проекта - Durian (напомню, кодовые названия первых двух проектов были Orange и Peach - апельсин и персик; дуриан - это фрукт, произрастающий в юго-восточной азии, выглядит как очень большой колючий огурец, имеет резкий специфический запах и приятный вкус). Известно, что это будет что-то фентезийное, с замками и драконами. Для подготовки концепции (conceptual art) в проекте используется текущая разрабатываемая версия MyPaint.

Version 1.0

Last updated 2009-11-12 22:44:52 YEKST

Ядро Linux за 10 минут (обзор)

portnov — Sat, 06 Mar 2010 18:20:39 +0300

Немного истории

Относительно подробную историю создания ядра Linux можно найти в известной книге Линуса Торвальдса «Just for fun». Нас из неё интересуют следующие факты:

Ядро создал в 1991 году студент университета Хельсинки Линус Торвальдс;
В качестве платформы он использовал ОС Minix, написанную его преподавателем Эндрю Таненбаумом, запущенную на персональном компьютере с процессором Intel 80386;
В качестве примера для подражания он использовал ОС семейства Unix, а в качестве путеводителя — сначала стандарт POSIX, а затем просто исходные коды программ из комплекта GNU (bash, gcc и пр).

Эти факты в значительной мере определили пути развития ядра в дальнейшем, их следствия заметны и в современном ядре.

В частности, известно, что Unix-системы в своё время разделились на два лагеря: потомки UNIX System V Release 4 (семейство SVR4) против потомков Berkley Software Distribution v4.2 (BSD4.2). Linux по большей части принадлежит к первому семейству, но заимствует некоторые существенные идеи из второго.

Ядро в цифрах

Около 30 тыс. файлов
Около 8 млн. строк кода (не считая комментариев)
Репозиторий занимает около 1 Гб
linux-2.6.33.tar.bz2: 63 Mb
patch-2.6.33.bz2: 10Mb, около 1.7 млн изменённых строк
Около 6000 человек, чей код есть в ядре

Об архитектуре ядра

Все (или почти все) процессоры, которыми когда-либо интересовались производители Unix-подобных ОС, имеют аппаратную поддержку разделения привелегий. Один код может всё (в т.ч. общаться напрямую с оборудованием), другой — почти ничего. Традиционно говорят о «режиме ядра» (kernel land) и «режиме пользователя» (user land). Различные архитектуры ядер ОС различаются прежде всего подходом к ответу на вопрос: какие части кода ОС должны выполняться в kernel land, а какие — в user land? Дело в том, что у подавляющего большинства процессоров переключение между двумя режимами занимает существенное время. Выделяют следующие подходы:

Традиционный: монолитное ядро. Весь код ядра компилируется в один большой бинарный файл. Всё ядро исполняется в режиме ядра;
Противоположный, новаторский: микроядро. В режиме ядра выполняются только самые необходимые части, всё остальное — в режиме пользователя;
В традиционном подходе позже появился вариант: модульное ядро. Всё исполняется в режиме ядра, но при этом ядро компилируется в виде одного большого бинарного файла и кучки мелких модулей, которые могут загружаться и выгружаться по необходимости;
И, конечно, всевозможные варианты гибридных архитектур.

Ядро Linux начиналось как монолитное (глядя на существовавшие тогда Unix-ы). Современное Linux-ядро модульное. По сравнению с микроядром монолитное (или модульное) ядро обеспечивает существенно бо́льшую производительность, но предъявляет существенно более жёсткие требования к качеству кода различных компонентов. Так, в системе с микроядром «рухнувший» драйвер ФС будет перезапущен без ущерба для работы системы; рухнувший драйвер ФС в монолитном ядре — это Kernel panic и останов системы.

Подсистемы ядра Linux

Существует довольно широко известная диаграмма, изображающая основные подсистемы ядра Linux и их взаимодействие. Вот она:

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

Системные вызовы

Уровень системных вызовов — это наиболее близкая к прикладному программисту часть ядра Linux. Системные вызовы предоставляют интерфейс, используемый прикладными программами — это API ядра. Большинство системных вызовов Linux взяты из стандарта POSIX, однако есть и специфичные для Linux системные вызовы.

Здесь стоит отметить некоторую разницу в подходе к проектированию API ядра в Unix-системах с одной стороны и в Windows[NT] и других идеологических потомках VMS с другой. Дизайнеры Unix предпочитают предоставить десять системных вызовов с одним параметром вместо одного системного вызова с двадцатью параметрами. Классический пример — создание процесса. В Windows функция для создания процесса — CreateProcess() — принимает 10 аргументов, из которых 5 — структуры. В противоположность этому, Unix-системы предоставляют два системных вызова (fork() и exec()), первый — вообще без параметров, второй — с тремя параметрами.

Системные вызовы, в свою очередь, обращаются к функциям более низкоуровневых подсистем ядра.

Управление памятью

Ядро Linux использует в качестве минимальной единицы памяти страницу. Размер страницы может зависеть от оборудования; на x86 это 4Кб. Для хранения информации о странице физической памяти (её физический адрес, принадлежность, режим использования и пр) используется специальная структура page размером в 40 байт.

Ядро использует возможности современных процессоров для организации виртуальной памяти. Благодаря манипуляциям с каталогами страниц виртуальной памяти, каждый процесс получает адресное пространство размером в 4Гб (на 32х-разрядных архитектурах). Часть этого пространства доступна процессу только на чтение или исполнение: туда отображаются интерфейсы ядра.

Существенно, что процесс, работающий в пространстве пользователя, в большинстве случаев «не знает», где находятся его данные: в ОЗУ или в файле подкачки. Процесс может попросить у системы выделить ему память именно в ОЗУ, но система не обязана удовлетворять такую просьбу.

Управление процессами

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

В истории было известно два типа многозадачности:

Корпоративная многозадачность.: В этом варианте каждый процесс передаёт управление какому-нибудь другому, когда сочтёт нужным. Это экономит время на переключение режимов процессора, но, очевидно, о надёжности такой системы говорить не приходится: зависший процесс не передаст управление никому. В современных ОС этот вариант не используется.
Вытесняющая многозадачность.: Ядро ОС выделяет каждому процессу определённый квант процессорного времени и «насильно» передаёт управление другому процессу по истечении этого кванта. Это создаёт накладные расходы на переключение режимов процессора и расчёт приоритетов, но повышает надёжность и производительность.

Переключение процессов в linux может производиться по наступлению двух событий: аппаратного прерывания или прерывания от таймера. Частота прерываний таймера устанавливается при компиляции ядра в диапазоне от 100Гц до 1000Гц. Аппаратные прерывания возникают чуть ли не чаще: достаточно двинуть мышку или нажать кнопку на клавиатуре, да и внутренние устройства компьютера генерируют прерывания. Начиная с версии 2.6.23, появилась возможность собрать ядро, не использующее переключение процессов по таймеру. Это позволяет снизить энергопотребление в режиме простоя компьютера.

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

Кроме многозадачности в режиме пользователя, ядро Linux использует многозадачность в режиме ядра: само ядро многопоточно.

Традиционные ядра Unix-систем имели следующую… ну если не проблему, то особенность: само ядро не было вытесняемым. Пример: процесс /usr/bin/cat хочет открыть файл /media/cdrom/file.txt и использует для этого системный вызов open(). Управление передаётся ядру. Ядро обнаруживает, что файл расположен на CD-диске и начинает инициализацию привода (раскручивание диска и пр). Это занимает существенное время. Всё это время управление не передаётся пользовательским процессам, т.к. планировщик не активен в то время, когда выполняется код ядра. Все пользовательские процессы ждут завершения этого вызова open().

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

Сетевая подсистема

Сетевая подсистема ядра ОС, теоретически, почти вся может выполняться в пространстве пользователя: для таких операций, как формирование пакетов TCP/IP, никакие привелегии не нужны. Однако в современных ОС, тем более применяемых на высоконагруженных серверах, от всего сетевого стека — всей цепочки от формирования пакетов до работы непосредственно с сетевым адаптером — требуется максимальная производительность. Сетевой подсистеме, работающей в пространстве пользователя, пришлось бы постоянно обращаться к ядру для общения с сетевым оборудованием, а это повлекло бы весьма существенные накладные расходы.

Сетевая подсистема Linux обеспечивает следующую функциональность:

Абстракцию сокетов;
Стеки сетевых протоколов (TCP/IP, UDP/IP, IPX/SPX, AppleTalk и мн. др);
Маршрутизацию (routing);
Пакетный фильтр (модуль Netfilter);
Абстракцию сетевых интерфейсов.

В различных Unix-системах использовалось два различных прикладных интерфейса, обеспечивающих доступ к функциональности сетевой подсистемы: Transport Layer Interface (TLI) из SVR4 и sockets (сокеты) из BSD. Интерфейс TLI, с одной стороны, тесно завязан на подсистему STREAMS, отсутствующую в ядре Linux, а с другой — не совместим с интерфейсом сокетов. Поэтому в Linux используется интерфейс сокетов, взятый из семейства BSD.

Файловая система

Виртуальная файловая система (VFS)

С точки зрения приложений, в Unix-подобных ОС существует только одна файловая система. Она представляет собой дерево директорий, растущее из «корня». Приложениям, в большинстве случаев, не интересно, на каком носителе находятся данные файлов; они могут находиться на жёстком диске, оптическом диске, флеш-носителе или вообще на другом компьютере и другом континенте. Эта абстракция и реализующая её подсистема называется виртуальной файловой системой (VFS).

Стоит заметить, что VFS в ядре Linux реализована с учётом идей из ООП. Например, ядро рассматривает набор структур inode, каждая из которых содержит (среди прочего):

Данные из on-disk inode (права доступа, размер файла и др);
Указатель на структуру, описывающую драйвер ФС, к которой принадлежит данный inode;
Указатель на струкруру операций с inode, которая, в свою очередь, содержит указатели на функции для создания inode, изменения его атрибутов и т.д., реализованные в конкретном драйвере ФС.

Аналогично устроены структуры ядра, описывающие другие сущности ФС — суперблок, элемент каталога, файл.

Драйверы ФС

Драйверы ФС, как можно заметить из диаграммы, относятся к гораздо более высокому уровню, чем драйверы устройств. Это связано с тем, что драйверы ФС не общаются ни с какими устройствами. Драйвер файловой системы лишь реализует функции, предоставляемые им через интерфейс VFS. При этом данные пишутся и читаются в/из страницы памяти; какие из них и когда будут записаны на носитель — решает более низкий уровень. Тот факт, что драйверы ФС в Linux не общаются с оборудованием, позволил реализовать специальный драйвер FUSE, который делегирует функциональность драйвера ФС в модули, исполняемые в пространстве пользователя.

Страничный кэш

Эта подсистема ядра оперирует страницами виртуальной памяти, организованными в виде базисного дерева (radix tree). Когда происходит чтение данных с носителя, данные читаются в выделяемую в кэше страницу, и страница остаётся в кэше, а драйвер ФС читает из неё данные. Драйвер ФС пишет данные в страницы памяти, находящиеся в кэше. При этом эти страницы помечаются как «грязные» (dirty). Специальный поток ядра, pdflush, регулярно обходит кэш и формирует запросы на запись грязных страниц. Записанная на носитель грязная страница вновь помечается как чистая.

Уровень блочного ввода-вывода

Эта подсистема ядра оперирует очередями (queues), состоящими из структур bio. Каждая такая структура описывает одну операцию ввода-вывода (условно говоря, запрос вида «записать вот эти данные в блоки ##141-142 устройства /dev/hda1»). Для каждого процесса, осуществляющего ввод-вывод, формируется своя очередь. Из этого множества очередей создаётся одна очередь запросов к драйверу каждого устройства.

Планировщик ввода-вывода

Если выполнять запросы на дисковый ввод-вывод от приложений в том порядке, в котором они поступают, производительность системы в среднем будет очень низкой. Это связано с тем, что операция поиска нужного сектора на жёстком диске — очень медленная. Поэтому планировщик обрабатывает очереди запросов, выполняя две операции:

Сортировка: планировщик старается ставить подряд запросы, обращающиеся к находящимся близко секторам диска;
Объединение: если в результате сортировки рядом оказались несколько запросов, обращающихся к последовательно расположенным секторам, их нужно объединить в один запрос.

В современном ядре доступно несколько планировщиков: Anticipatory, Deadline, CFQ, noop. Существует версия ядра от Con Kolivas с ещё одним планировщиком — BFQ. Планировщики могут выбираться при компиляции ядра либо при его запуске.

Отдельно следует остановиться на планировщике noop. Этот планировщик не выполняет ни сортировки, ни слияния запросов, а переправляет их драйверам устройств в порядке поступления. На системах с обычными жёсткими дисками этот планировщик покажет очень плохую производительность. Однако, сейчас становятся распространены системы, в которых вместо жёстких дисков используются флеш-носители. Для таких носителей время поиска сектора равно нулю, поэтому операции сортировки и слияния не нужны. В таких системах при использовании планировщика noop производительность не изменится, а потребление ресурсов несколько снизится.

Обработка прерываний

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

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

В ядре Linux в результате любого аппаратного прерывания управление передаётся в функцию do_IRQ(). Эта функция использует отдельную таблицу зарегистрированных в ядре обработчиков прерываний, чтобы определить, куда передавать управление дальше.

Чтобы обеспечить минимальное время работы в контексте прерывания, в ядре Linux используется разделение обработчиков на верхние и нижние половины. Верхняя половина — это функция, которая регистрируется драйвером устройства в качестве обработчика определённого прерывания. Она выполняет только ту работу, которая безусловно должна быть выполнена немедленно. Затем она регистрирует другую функцию (свою нижнюю половину) и возвращает управление. Планировщик задач передаст управление зарегистрированной нижней половине, как только это будет возможно. При этом в большинстве случаев управление передаётся нижней половине сразу после завершения работы верхней половины. Но при этом нижняя половина работает как обычный поток ядра, и может быть прервана в любой момент, а потому она имеет право исполняться сколь угодно долго.

В качестве примера можно рассмотреть обработчик прерывания от сетевой карты, сообщающего, что принят ethernet-пакет. Этот обработчик обязан сделать две вещи:

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

Соответственно, первое выполняет верхняя половина обработчика, а второе — нижняя.

Драйвера устройств

Большинство драйверов устройств обычно компилируются в виде модулей ядра. Драйвер устройства получает запросы с двух сторон:

От устройства — через зарегистрированные драйвером обработчики прерываний;
От различных частей ядра — через API, который определяется конкретной подсистемой ядра и самим драйвером.

Version 1.0

Last updated 2010-03-05 20:25:06 YEKST

Системы контроля версий. Git, Gitosis

portnov — Sat, 06 Mar 2010 17:59:29 +0300

Начну я с краткого введения в системы контроля версий вообще.

Что такое управление версиями и зачем оно?

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

Создаем директорию MyApplication, в ней - собственно файлы программы (скажем, *.c). Далее начинается итерационный процесс: написали некоторое количество кода → скомпилировали → запустили → обнаружили ошибки или недоработки → отредактировали исходники → … Всё просто, в целом. Но через некоторое время начинаются нетривиальные вещи.

Неочевидности:

Последнее изменение сделало программу хуже, чем она была до того. Хочется вернуть всё "как было". Хорошо, если не успели закрыть редактор - делаем $Undo. А если закрыли?
Хотим приделать к программе новую функциональность, но сразу ясно, что, во-первых, сразу после написания она будет глючить (т.к. еще не отлажена), а во-вторых, в сложной программе добавление новой функциональности может добавить ошибок в ранее работавшую часть программы. Хочется, в случае чего, откатиться к заведомо работающему варианту и начать всё сначала.
Если программа предназначена не только для вас лично, то вам придется делать "релизы", т.е. выпускать заведомо работающие версии программы. Для подготовки релиза вам придется фиксить некоторое количество багов. Это довольно скучный процесс, хочется разбавлять его добавлением новых возможностей в программу (это, как правило, интереснее). Но нельзя: добавление новых фич обязательно добавит багов, и вы никогда не доедете до релиза.

Первое, что приходит в голову для решения всех этих проблем - резервные копии. Скажем, каждую работающую версию программы упаковывать в MyApplication_v0.001.tar.gz, в случае чего - откатываться. Для подготовки к релизу - сделать копию директории MyApplication, в которой только фиксить баги, а в основной - добавлять функционал. При этом подходе через некоторое время разработки у вас появится куча *.tar.gz и не меньше копий рабочей директории. Очень быстро вы начнете путаться, где что.

Если вы разрабатываете программу не в одиночку, а, скажем, с группой товарищей, появляются новые неочевидности:

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

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

Все эти проблемы призваны решить специальные программы - системы контроля версий (version control systems, vcs).

Общие свойства VCS

Если вы работаете с vcs, то у вас есть место, где хранится вся история изменений в программе - это место называется репозиторий (repository). Для внесения изменений в программу вам нужно получить копию текущей разрабатываемой версии - она называется вашей рабочей копией (working copy). Процесс получения рабочей копии традиционно называется словом "чекаут" (checkout). В случае коллективной разработки, вам придется поддерживать актуальность вашей рабочей копии (проверять, что там остальные наработали) - это обычно называется "апдейт" (update). Чтобы ваши изменения попали в репозиторий, вам нужно сделать коммит (commit) (еще это называется словом checkin). Часто словом commit называют собственно сам набор изменений, зафиксированный этой операцией (более точный термин - changeset). Каждое зафиксированное изменение называют ревизией. Вы можете в любой момент откатить свою рабочую копию к любой предыдущей ревизии - это называется revert.

Для того, чтобы отслеживать такие вещи, как релизы, или варианты рефакторинга программы, или тестировать версии с новыми функциями - в репозитории создаются ветви разработки (branches). Для согласования хода разработки в разных ветках (она может вестись, и обычно ведется, параллельно) время от времени делают слияние веток (merge) - когда к одной ветке применяются те же изменения, что были проделаны в другой. Если какое-то место какого-то файла было по-разному изменено в разных ветках, при слиянии возникает конфликт (merge conflict) - его приходится решать вручную, выбирая один из вариантов или как-то логично их объединяя.

Так как ревизий в репозитории обычно довольно много, возникает необходимость некоторые из них как-то помечать (например, выпущенные релизы, или просто состояния программы, в которых она заведомо работала). Такие пометки называют тегами (tags). Таким образом, теги - это поименованные ревизии в репозитории.

Автоматизация всех перечисленных операций - дело VCS.

Централизованные vs распределенные VCS

Всё множество VCS можно разделить на два класса - централизованные и распределенные.

В случае с централизованной VCS репозиторий хранится на одном сервере, и все разработчики работают с ним. Очевидное преимущество: простое управление выпуском релизов и вообще ходом развития программы, раз весь код в одном месте. Очевидный недостаток: если с сервером что-то случится, работа всех разработчиков пропадет (даже в случае регулярных бэкапов - пропадет работа всех разработчиков, скажем, за последнюю неделю). Известные примеры централизованных vcs - CVS, Subversion, Perforce.

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

Раз у каждого есть полная копия репозитория, работа 'всех' разработчиков пропасть не может вообще.
Часто выполняемые операции - прежде всего, commit - происходят почти мгновенно, т.к. не требуют соединения по сети.
Каждый разработчик может создавать в своем репозитории ветки для каких-то экспериментов, всем остальным даже не нужно знать об этом.
Т.к. в распределенных VCS предполагается регулярная синхронизация репозиториев, в них гораздо более эффективно реализована операция слияния веток (здесь это одна из базовых операций, в отличие от централизованных VCS, где это делается нечасто).
Каждый разработчик может взять ("утянуть") у другого один или несколько коммитов, применив их к своему коду.

Git

Git - это одна из распределенных VCS (distributed version control system, dvcs). Другими примерами dvcs являются Mercurial, Bazaar, Monotone.

Git выделяется на их фоне главным образом из-за того, что он применяется для разработки ядра Linux (http://www.kernel.org). Собственно, именно для этого Git и разрабатывался. Ядро Linux - весьма немаленький проект, как по объему исходного кода, так и по числу участников, поэтому при разработке Git большое внимание было уделено производительности и легкости слияния веток.

Создание репозитория

Одна из особенностей распределённых VCS и Git в частности состоит в лёгкости создания репозитория. В случае svn, например, вам надо поднимать специальный сервер, настраивать его… В случае с Git, вы даёте одну команду:

$ git init

и всё, в текущей директории готов репозиторий Git. Вся информация репозитория хранится в директории ./.git.

Bare-репозитории.Иногда бывает нужно создать репозиторий без рабочей копии (т.е. состоящий только из директории .git). Такие репозитории называются bare-репозиториями. Директория такого репозитория содержит всё то же, что содержит директория .git обычного репозитория. Для создания bare-репозиториев предназначена опция --bare.

Коммит

Ещё одна особенность Git - он не отслеживает автоматически все подряд файлы, находящиеся в директории проекта. Вместо этого, у него есть такое понятие как индекс. Индекс - это некоторое временное хранилище, в котором Git хранит список изменившихся файлов. Чтобы сообщить Git-у, что файл изменился, надо дать команду

$ git add имя-файла

(конечно, можно добавить все файлы по маске, или сразу всю директорию). У команды git add есть интересные параметры. git add --interactive покажет список изменившихся файлов и позволит вам в интерактивном режиме выбрать, какие из них включать в коммит. git add --patch работает аналогично, но не с файлами, а с отдельными изменения (hunks в терминологии diff).

Чтобы сделать собственно коммит, используется команда

$ git commit

или

$ git commit -a

чтобы предварительно добавить в индекс все изменившиеся файлы. Команда git commit -i (--interactive) работает аналогично последовательности git add --interactive; git commit.

Если сразу после коммита вы обнаружили, что что-то забыли включить в него, можно поправить:

$ git commit --amend # Добавить последние изменения в последний коммит, "заодно".

Особенность Git состоит в том, что ревизии (коммиты) обозначаются не номерами, как, например, в svn или cvs, а 40-значными идентификаторами типа a21b96…. Идентификаторы можно сокращать до первых нескольких знаков, лишь бы они однозначно определяли коммит. Кроме того, если нужный вам коммит помечен тегом, то можно использовать имя тега вместо идентификатора коммита. На последний коммит в текущей ветке можно также ссылаться по имени HEAD, на предпоследний - HEAD^, пред-предпоследний - HEAD^\^ итп. Существуют и другие способы обозначить нужный коммит, подробности см. в документации.

Состояние репозитория

Увидеть, какие файлы были изменены, добавлены итп после последнего коммита можно командой

$ git status

Сами изменения, сделанные с момента последнего коммита, можно посмотреть командой

$ git diff

У этой команды есть варианты: git diff <идентификатор> - посмотреть изменения с указанного коммита по текущее состояние, git diff <идентификатор1> <идентификатор2> - различия между двумя ревизиями.

Посмотреть журнал последних коммитов - git log.

Работа с клонированным репозиторием

Чтобы создать новый репозитоий, взяв за основу существующий, используется команда

$ git clone git://remote.server/repo.git

Кроме собственного протокола, git поддерживает http://, ssh:// и мн. др.

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

$ git pull

Если вам разрешено вносить изменения в исходный репозиторий (это называется push access, предполагает договоренность с владельцем репозитория, и, в зависимости от протокола доступа (ssh или еще что-то), какие-то пароли итп), это делается командой

$ git push

При этом ваши изменения вливаются в репозиторий, который вы клонировали.

Карман

Git ппредоставляет такую удобную вещь, как "карман" (stash). Это временное хранилище для изменений. Рассмотрим следующий простой пример. Вы начали вносить изменения в программу, но вдруг обнаружили, что забыли переключиться на свою ветку и правите чужую. Делать commit в такой ситуации бессмысленно. Тогда достаточно сделать следующее

$ git stash # спрятать изменения в карман

$ git checkout my-branch # переключиться на нужную ветку

$ git stash apply # применить изменения из кармана

$ git stash clear # очистить карман

Теги, ветки

Пометить только что созданный коммит можно командой

$ git tag имя-тега

Любой другой коммит помечается так:

$ git tag имя-тега идентификатор-коммита

Посмотреть список веток в репозитории -

$ git branch

(изначально создается одна ветка под названием master).

Создать новую ветку -

$ git branch имя-ветки

или

$ git branch имя-ветки идентификатор-коммита-начинающего-ветку

Переключиться на вновь созданную или любую другую ветку (в рабочей копии окажутся файлы той ветки, и последующие коммиты будут заноситься в нее) -

$ git checkout имя-ветки

С тем же успехом этой командой можно переключиться на любой коммит - git checkout some-commit. Командой git checkout -b new-branch commit-id можно переключиться на указанный коммит и сразу создать новую ветку, начинающуюся с него.

Влить изменения из другой ветки в текущую -

$ git merge имя-ветки-с-которой-сливаем

Можно взять из другой ветки один конкретный коммит (например, багофикс) -

$ git cherry-pick идентификатор-коммита

Merge и Rebase

Постановка задачиКак я уже говорил, в случае распределённых VCS объединение (merge) веток - очень частая операция. Но в некоторых ситуациях этой операции оказывается недостаточно. На самом деле, merge делает следующее. Пусть у нас есть такая схема:

(здесь овалами обозначены коммиты; цветом я выделил коммиты в ветке yours, остальные - в ветке master). Так вот, команда git merge yours (при условии, что вы находитесь в ветке master), сделает из этой диаграммы следующее:

Здесь "New commit" - это коммит, содержащий все изменения коммитов YC1 и YC2 с предыдущей схемы. Таким образом, изменения из ветки yours будут перенесены в конец ветки master. Заметим, что это изменяет саму ветку master. В случае, когда ветка master находится в некотором "главном" репозитории, а ветка yours - в вашем, это означает, что объединение может выполнять только владелец главного репозитория. И ему же придётся разрешать все конфликты. Однако во многих случаях владелец главного репозитория не желает (не может) вникать во все эти конфликты. Для таких случаев предназначена команда git rebase master (находясь в ветке yours). Она сделает из первой диаграммы следующее:

Т.е. получится, что теперь ваша ветка будет базироваться на последнем коммите ветки master (и, таким образом, будет включать все изменения ветки master). Конечно, при такой операции тоже возможны конфликты, но разрешать их будете вы, а не владелец ветки master. Ему достаточно будет сделать git merge yours - такое объединение теперь пройдёт заведомо без конфликтов.

Кроме этого, команда git rebase -i (--interactive) позволяет делать ещё многое. По этой команде откроется текстовый редактор со списком коммитов в вашей ветке. Изменяя этот список, вы можете, например, исключить некоторые коммиты из операции, или попросить подредактировать некоторые. Отсюда же можно выполнять операцию squash - когда изменения нескольких подряд идущих коммитов сливаются в один.

Работа с удалёнными репозиториями

Как я уже многократно говорил, модель Git предполагает, что в одном проекте используется множество репозиториев. Соответственно, нужны некие инструменты для работы с другими (отличными от текущего) репозиториями. Благодаря тому, что git прозрачно поддерживает разные протоколы доступа, принципиальной разницы между репозиторием, находящимся на данном компьютере и репозиторием, находящимся где-то в интернете нет.

Для работы с удалёнными репозиториями используется команда git remote с подкомандами. Команда

git remote show

покажет список зарегистрированных удалённых репозиториев. Если вы получили свой репозиторий командой git clone, то у вас уже есть одна запись в git remote show под названием origin - она описывает исходный репозиторий. Новые репозитории добавляются командой вида

git remote add reponame ssh://host/path/to/repo.git

Для обмена кодом с удалёнными репозиториями служат всё те же команды - git pull, git push, git cherry-pick. Например, после предыдущей команды команда

git push reponame

пошлёт все изменения в текущем репозитории в репозиторий на хосте host.

Тут же следует заметить, что команду git push редко имеет смысл выполнять в направлении не-bare-репозиториев. Ведь если в репозитории есть рабочая копия, то, вероятно, в ней есть незафиксированные изменения. Изменение состояния репозитория без предварительной фиксации изменений вряд ли приведёт к чему-то хорошему. Обычно вместо того, чтобы делать git push vanya-repo, лучше позвонить этому Ване и сказать "сделай, пожалуйста, pull моих изменений". А команду git push обычно выполняют в направлении репозитория на сервере, который предусмотрительно создаётся в виде bare-репозитория. Или любого другого репозитория, если заранее известно, что в нём точно не может быть никаких своих изменений.

Gitosis

Одним из следствий распределённой модели VCS является отсутствие проблемы разграничения прав доступа. У каждого разработчика есть свой репозиторий, и он имеет на него все возможные права. "Главный" репозиторий принадлежит главному разработчику, и главный разработчик может брать у других изменения и вносить их в свой (главный) репозиторий.

Однако, во многих случаях распределённые VCS используются в централизованном режиме. В такой схеме главный репозиторий не принадлежит никому, push в него могут делать все кому положено (а не только один человек). На самом деле, эта схема оправдана только в двух случаях:

Все разработчики находятся в разных локальных сетях, за NAT-ами итп, и из-за этого не могут делать pull друг у друга; в этом случае для обмена кодом нужен отдельный сервер, видимый из всех сетей (например, в интернете);
Ситуация, когда нужно организовать публичный хостинг - например, аналог github.org или gitorious.org.

В таких ситуациях нужно раздавать разные права на центральный репозиторий разным разработчикам. Сам Git не имеет никакой модели прав доступа по указанной выше причине. Однако это можно организовать с помощью отдельного ПО. Самый распространённый вариант - gitosis. Gitosis предоставляет доступ к репозиториям, расположенным на сервере (сложенным в одной директории), по протоколу ssh.

Gitosis использует для хранения своей конфигурации git-репозиторий. Для авторизации используются SSH-ключи разработчиков.

Для настройки gitosis нужно:

Создать системного пользователя git, имеющего доступ ко всем репозиториям на сервере (но больше никуда);
Разрешить ему вход по ssh; я не привожу конкретных команд, как это делать - это описано в документации gitosis; Суть в том, что средствами ssh-сервера этому пользователю разрешается выполнять только очень небольшой набор команд (git push итп);
В репозиторий с настройками gitosis, в папку keydir, положить открытые ssh-ключи всех разработчиков, назвав файлы по шаблону user@host;
Написать конфиг для gitosis, в котором описать, какие разработчики имеют доступ к каким проектам.

Пример конфига:

[gitosis]

[group gitosis-admin]

writable = gitosis-admin

members = kossnocorp@kossnocorp-desktop

[group octolab]

writable = zfk

members = kossnocorp@kossnocorp-desktop edward@amilo

После этого доступ к репозиториям возможен по URL ssh://git@server.org:repo.git. Заметим, что доступ всегда выполняется под пользователем git (это тот пользователь, от имени которого работает на сервере gitosis). Разработчику совсем не обязательно иметь свою учётную запись на сервере.

Презентация к докладу: http://lug-mgn.ru/files/git/vcss-presentation.ps

Version 1.0

Last updated 2009-11-25 01:04:21 YEKST

Статьи

Настраиваем VPN Магинфо средствами NetworkManager

Материалы семинара 19.03

Настройка VPN от Магинфо на роутере DLink DIR-300 rev.B1 с прошивкой DD-WRT

Общие настройки

Добавляем нужные роуты

Немного плясок с бубном

Настройка интернета Магинфо в BSD

Настройка интернета Магинфо в Linux v.2

Настройка интернета магинфо в Linux

Настройка через NetworkManager в Ubuntu 10.04+, Fedora Russian remix и других дистрибутивах (другие не проверял)

Старый способ - правка конфигурации pptp

Документирование PHP-кода

Table of Contents

1 Введение

2 phpdoc

2.1 Теги

2.2 Пакеты

3 phpDocumentor

4 Doxygen

5 Сравнение

Материалы доклада "Open source OLAP-система Jedox Palo BI Suite"

MyPaint. Обзор и What's new

Обзор

Что нового

Интернационализация

Палитра

Диалог слоёв

Группы кистей

Поддержка наклона пера

Подбор цвета

Использование в Durian

Ядро Linux за 10 минут (обзор)

Немного истории

Ядро в цифрах

Об архитектуре ядра

Подсистемы ядра Linux

Системные вызовы

Управление памятью

Управление процессами

Сетевая подсистема

Файловая система

Виртуальная файловая система (VFS)

Драйверы ФС

Страничный кэш

Уровень блочного ввода-вывода

Планировщик ввода-вывода

Обработка прерываний

Драйвера устройств

Системы контроля версий. Git, Gitosis

Что такое управление версиями и зачем оно?

Общие свойства VCS

Централизованные vs распределенные VCS

Git

Создание репозитория

Коммит

Состояние репозитория

Работа с клонированным репозиторием

Карман

Теги, ветки

Merge и Rebase

Работа с удалёнными репозиториями

Gitosis