25 августа 1991 года в 20:57:08 GMT некий студент из Хельсинки с адресом torvalds@kruuna.helsinki.fi отправил в конференцию comp.os.minix сообщение под заголовком «What would you like to see most in minix?», в котором рассказал, что пишет бесплатную операционную систему, свободную от кода minix (чисто хобби, не будет такой большой и профессиональной, как gnu), в которой уже вроде работают bash 1.08 и gcc 1.40, но нет переносимости, и вряд ли когда-нибудь она будет работать с чем-то помимо ATшных винчестеров.

От себя: Читая этот блог, вы читаете его с Linux сервера Неплохая бесплатная операционнная система получилась! Что уж говорить про Linux-ы Google …

Долго искал — можно ли как-то приблизиться к сервису, близкому ShellGuard, и нашел максимально хорошее решение — PuTTY Connection Manager. Эта программа делает следующее — она запускает на каждую консоль новое окно PuTTY как процесс, но интегрирует их в одно Windows окно, делая вкладки (Tabs), переключаться между которыми теперь можно через Ctrl + Tab. Работает очень хорошо, но все таки остался неприятный осадок — было бы замечательно, если бы порядок переключения делался в Most Recent порядке (между наиболее недавно использованными табами). Но этого нет. Еще хочется добавить из минусов — очень медленно развивается разработчиками. И хотя можно запросить и проголосовать за какую либо новую фичу, что-то мне подсказывает, увидеть ее потом можно через N-ое количество лет.

Кстати, как ShellGuard, так и PuTTY — работают с SSH ключами. Если вы не используете SSH ключи для авторизации (то есть работаете по старинке — вводя каждый раз пароль), то очень рекомендую это сделать — удобно, быстро и более безопасно! Конечно, сами ключи для авторизации необходимо защитить паролем, но его надо ввести один раз (для ShellGuard — только при первой сессии и для PuTTY вводится при запуске Pageant из состава PuTTY)

Правильно так: когда пишут encode to UTF-8, это значит, что внутри перла строка с UTF-8 данными остается как есть, но флаг UTF-8 убирается, и perl начинает вести себя со строкой так, как будто там бинарные (octet) байтовые данные (то есть посути, строка внутри перла перестает быть UTF8, хотя слово «encode» несет в себе другой смысл). И наоборот — decode to UTF-8 -> UTF8 флаг ставится (то есть для perl-а строка становится UTF8).

P.S. В Perl есть такая функция — encode (модуль Encode). Смысл ее в том, чтобы перевести строку из внутреннего содержания на perl (которое всегда UTF-8 внутри, т.е. Unicode символы) в байтовую последовательность, которая бы отражала ту кодировку, которую ей указали (то есть раз байтовая — значит всегда utf8 флаг в результате отсутсвует). Если мы делаем $result = encode(‘utf-8′, $string), то результат как раз будет в том, что флаг utf8 будет просто снят для $result и в реальности никакого переводирования не будет (то есть побайтово внутри perl-а $string & $result будут содержать одни и те же байты, только $string еще будет иметь взведенный utf8 флаг). И это как раз вписывается в те понятия, которые я описал ранее. Для decode и байтового UTF8 всё обратно — флаг utf8 просто ставится в $result.

Вот такая абракодабра… Будьте внимательны!

Я сам программирую динамические веб сайты (CGI) только на Perl. Никогда не использовал PHP. Это не только потому, что я фанат Perl, но и дань эффективности — под Perl много модулей, много возможностей, и при грамотном подходе сайты на Perl будут работать быстрее PHP — ведь Perl код после компиляции хранится в памяти в виде байт кода (типа «Пи кода» кода в Pascal). А если знаешь Perl, то и разработка может идти гораздо быстрее.

До недавнего времени я использовал технологию Apache + mod_perl + Embperl, а сам внешний WWW сервер имел фронтенд -Apache + mod_accel либо еще лучший вариант — nginx  (оба — реализуют проксирование). Лет 8 назад это было отличным решением, когда я начал использовать эту технологию. Но сейчас она устарела и сложна в использовании.

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

• PSGI технология, а также ее реализация через модули Plack
• Starman — perl сервер, с режимами pre-fork, контроля количества процессов и многое другое. Вообщем, почти как apache.
• Dancer — отличное решение для реализации своих PSGI приложений, но с более простым программированием.

Сейчас немного подробнее

PSGI — недавно придуманный стандарт для Perl, который реализует простой и понятный программисту подход — вместо написания CGI скриптов и всей этой ваши с передачей параметров серверам и т.п.., очень умный человек (Tatsuhiko Miyagawa) придумал (правда взяз за основу наработки из Python) простой подход — любое приложение (будь то скрипт или группа скриптов)  оформляется в виде обычной perl функции, которая чётко принимает и возвращает определенные параметры: принимает ссылку на хеш, в котором есть и заголовки HTTP, и служебные заголовки (вместо старых в CGI переменных окружения), а возвращает ссылку на массив из трех элементов: HTTP ответ, ссылку на массив заголовков ответа и ссылку на массив данных (HTTP BODY). Просто и со вкусом! Причем, можно возвращать и ссылку на код функции для реализации stream потоков. То есть в PSGI можно реализовать любой вид сервера — простой, отдающий потоковые данные (типа видео, например), либо удерживающее соединение (Comet технология). Но и это не все. Прелесть такой структуры функции PSGI в том, что одна функция может вызывать другую PSGI, но при этом делающее что-то своё. То есть другими словами — стек вызова. Называется это — middleware. А Plack служит клеем — имеет в своем составе сервис функции для формирования такого стека.

И, конечно же, если подумать, нужен сам сервер, который будет принимать TCP соединения, парсить заголовки и формировать хеш для PSGI, вызывать его и отдавать ответ. И таких серверов написано уже много. Один из них — Starman. Он, практически, выполняет те же функции, что выполняла бы связка Apache + mod_perl, только гораздо эффективнее, так как он проще, и нет тех «костылей», которые были приделаны в apache & mod_perl для их функционирования.

А что же делает Dancer? Он называется типом Frameworks в терминологии Plack. Он для сервера Starman работает как PSGI, но вы сами пишите на perl через предоставляемые Dancer-ом функции, которые облегчают вам жизнь. Dancer сам парсит входные данные от Starman, формирует их в удобный вид для обработки в perl и также формирует обратные заголовки и данные. К тому же, Dancer может работать без Starman — он имеет свой простой вебсервер. Также, раз Dancer может работать как PSGI функция, его можно вызывать из под любого сервера Plack типа, а также на нем можно написать свои middleware. Вообщем, тут вам как ваша фантазия и профессионализм подскажет.

Здесь на английском официальная инструкция, как это сделать. Основной смысл — провайдер ставит записи CNAME вместо PTR в обратной зоне (IN-ADDR.ARPA), а вы уже меняете на своем DNS настройки. В примере дан более развернутый пример, когда провайдер описывает записи для целой подзоны, например сетки /27 (32 машины) и указывает NS записи вашего DNS. Можно сделать проще для одного IP — провайдер ставит на вас CNAME вместо PTR (но не NS), CNAME указывает на ваш доменный адрес (на адрес под вашим доменом), для которого вы уже описываете PTR запись. Тем самым, если захотели другое имя для IP, меняете его у себя в DNS и телемаркет…

Если не знаете, зачем это, то знайте: обратное разрешение нужно для более правильной работы e-mail (если у вас есть почтовый сервер — для его IP это лучше сделать ). В противном случае, письма, оправленные через ваш SMTP, могут «отвегаться» большинством почтовых релеев (relay).

1. В компьютерных технологиях, стандартом часового пояса времени является НЕ ЛЕТНЕЕ ВРЕМЯ. Везде, в компьютерных системах, это подчеркивается — есть опция «Летнее время». То есть, если стоит пометка, то время летнее, и к стандартному сдвигу для данной временной зоны добавляется час. То, что приняли в России — это бред. Выходит, что РФ теперь будет жить всегда по «летнему времени». Придется ждать, когда везде в компьютерных системах (включая мобильники) для городов РФ сдвиг будет перенесен на час вперед для всех городов (см. след. пункт)
2. Теперь везде, где есть временные зоны (сотовые телефоны, компьютеры) россиянину надо будет выбирать не только свою зону, но и всегда ставить опцию летнего времени. А если ее нет — то придется всегда вместо своего города в базе зон выбирать другой город, который восточнее на 1 час. В общем, будет бардак. Не надо надеется, что везде эти базы зон будут оперативно обновлены — телефоны не перепрошьют, компы, если и обновятся, то не скоро.
3. Еще один очень неприятный момент: со следующей зимы все в России будут жить с большей разницей во времени с теми странами, где часы переводят. Пример — сейчас Москва зимой в зоне GMT +3 (что значит — для получения московского времени надо ко времени Гринвича — GMT — добавить 3 часа), европейские города — GMT +1. Это значит, что зимой разница между ними — 2 часа. Весной Европа и мы перейдем на летнее, Москва станет GMT +4 (в комп. системах это как «GMT +3″ + летнее время), Европа GMT +2. Разница попрежнему будет составлять два часа. А вот осенью случится то, что мне лично не нравится. Европа станет снова GMT +1, а Москва так и останется GMT +4. Разница времени зимой с Европой будет 3 часа. Я не беру в пример более восточные города РФ, а также города в США — везде разница с ними увеличится на час, чего никогда не было. Получается, что соотечественники за рубежом будут вынуждены звонить своим родственникам в Россию еше раньше, чтобы те не успели лечь спать. Также, это скажется на бизнесе между РФ и Европой. Европейское телевидение станет на всю зиму еще больше отставать по времени (например, те кто смотрит спутниковое — они это почувствуют). Тут еще надо подумать, не будет ли это так же плохо для населения, как то, когда стрелки переводили.

Остался еще неприятный момент, что ПО компьютеров придется дорабатывать и ждать обновлений — сейчас Windows & Unix автоматически переводят время, и без обновлений, осенью масса компьютеров просто некорректно переведет время. Но даже если оператор и вернет время обратно вручную, этого будет мало — придется ставить временной пояс не своего города, иначе система будет некорректно вычислять Гринвическое время, что также приведет к сбоям и проблемам. Вообщем, это будет что-то типо второй проблемы Y2K, только не для всего мира, а для РФ.

Непонятно, чем думали, когда решили весной последний раз перевести часы…

Для решения этой проблемы надо просто напросто добавить строку map archive = no в smb.conf файл. После перезапустить samba: service smb stop & service smb start

Итак, библиотека распознавания образов — OpenCV — упорно не хочет работать на Linux Fedora Core 13 (FC13) под 64 битами! Причем как версия 1.1, так и версия 2.2. Причем,  баг проявлялся на уровне мистики — все компилированные версии opencv падали в segmentation fault (core file), и только на 64 бит, а в интернете про эту проблему совсем ничего — как будто ее и нет!  Если ставить opencv из RPM, то можно поставить 2.0, но и с ней есть проблемы (не работал perl модуль Image::ObjectDetect — сейчас он работает, но с версии 2.1). Нужна была либо 1.1, либо выше 2.0. А вот если скачать 2.2 с сайта и собрать — она нормально собереться, но при работе с ней ваши программы упорно будут выпадать в core файлы (segmentation fault). То же касается версии 1.1. Вообщем, гуглил муглил я, копался в core файлах с отладчиком gdb и выяснил, что падает она в cvCanny функции. И нашел я вот этот баг. И кто бы мог подумать, что это глюки не самой OpenCV! Я то все время думал, что разработчики opencv виноваты. Оказалось, что проблема куда глубже — компилятор GCC 4.4.3 и ранее имел баг при оптимизации кода. Результат — некоторые программы и библиотеки под 64 битами могут доходить до segfault. Не стал исключением и OpenCV (сколько таких скрытых багов могло «подтянуться» к другим библиотекам и программам — можно только гадать). Вообщем, проблема решилась обновлением GCC компилятора из репозитария Fedora Core 13 и последующей перекомпиляцией OpenCV. После проверил — обе версии — 1.1 & 2.2 работали на отлично.

В MySQL есть такая особенность для таблиц типа MyISAM — операции изменения таблицы (INSERT/UPDATE/DELETE) имеют более высокий приоритет перед SELECT. Представим себе такую картину: к MySQL поступает сразу несколько запросов  в таком порядке: SELECT (1) -> UPDATE (2) -> SELECT (3) -> SELECT (4). Все эти запросы — от нескольких клиентов (сессий) и все — на работу с одной и той же таблицей (для простоты понимания). Первый SELECT, предположим, занимает 2 сек времени на выполнение. Если бы не было UPDATE, то остальные селекты могли бы исполняться в параллель — таблица ведь не меняется, данные тоже, почему бы не дать другим клиентам тоже выполнить запросы… Но, поскольку, есть UPDATE (то же было бы для случая DELETE/INSERT), MySQL заблокирует таблицу полностью при первом же случае (в нашем примере сразу же после отработки первого SELECT, который поступил раньше UPDATE), т.е. он ждет выполнения первого селекта (2 сек) для блокировки. За эти две секунды никто не может получить доступ к таблице, остальные SELECT будут ждать выполнения UPDATE (вень у него более высокий приоритет пол умолчанию), а UPDATE ждет первого SELECT. Все… Это пипец… Если у вас не загруженный сервак, то вас это беспокоить не будет — никто не будет наступать друг другу на пятки. А если сервак загружен, эту ситуацию можно сравнить с давкой в торговом центре, где ажиотаж, но при этом security решили пропустить без очереди VIP персону…

Какой выход? Оказывается, довольно простой. Один из вариантов — изменить по умолчанию приоритет операций для изменения таблиц (т.е. для UPDATE/INSERT/DELETE) — опция --low-priority-updates при запуске mysqld. Но это слишком глобальный способ, и вряд ли хороший. Я не вдумывался в его смысл, но думаю, раз придумали такой приоритет, то значит это кому то нужно.

Есть способ второй — найти такие узкие места в программе, где есть вместе долгоисполняемые SELECT (например большие JOIN), а также где рядом исполняется INSERT/DELETE/UPDATE на те же таблицы. И вот для тех INSERT/DELETE/UPDATE добавить слово LOW_PRIORITY в запросе. И все! На 99% вы устраните это узкое место и будете удивлены, насколько все пропрет Представим, что будет после. Если встретился долгий SELECT, а поступил также, например UPDATE, но уже с LOW_PRIORITY, а за ним в очереди другие SELECT, то другие SELECT будут исполняться сразу же в параллель вместе с первым длинным по времени, даже пока он не закончился. А уже после будет работать UPDATE и никому не мешать. Вообще, есть больше рекомендаций от самой MySQL.ORG.

Давайте сначала поймем, зачем он вам нужен.

Если вы один программист, то вот преимущества git перед ситуацией, когда вы его не используете:

1. В одном репозитарии (условно — одна папка) у вас хранится сразу вся история проекта с разными версиями. Вы можете создавать экспериментальные ветки, в случае успешного кода их затем объединять в стабильные ветки. Можно легко переходить в «прошлое». Например, можно быстро устранить баг в стабилной версии, а затем продолжать работать в экспериментальной альфа-версии.
2. Легко просматривать, что вы изменили вчера и сейчас. Удобно, когда вы приходите утром на работу и хотите вспомнить, на чем же вы остановились.
3. Заодно — git, выходит само собой, удобное средство резервирования и синхронизации. Вы можете разместить репозитарий на сервере, и с него подтягивать дома рабочие файлы, которые делали на работе,  а после правок заливать изменения обратно.
4. В git — каждый клонированный репозитарий - не только рабочая площадка, но также и полноценный репозитарий. Если вы работали на ноутбуке, а сегодня накрылся ваш сервер с репозитарием, то ваша локальная версия на ноуте — опять же, репозитарий со всей «историей».
5. Для git не надо online - вам достаточно «подтянуть» с сервера изменения, если были, и отключить ноутбук от интернета. Затем, работайте хоть в самолете! Делайте коммиты, пишите и просматривайте, что вы изменили. Только лишь, когда вы захотите «сбросить» все изменения в ваш главный репозитарий, только тогда вам нужен инет.

Если же вы команда, то преимущества те же, что выше, но также к ним добавляется возможность легкого ведения группового проекта. Самый замечательный пример, что все это отлично работает — ядро Linux — именно оно ведется Git-ом, и даже единичное увеличение подверсии ядра включает в себя большое количество commit-ов и работу большого количетва программистов.

Git, по моему опыту, гораздо понятнее программисту, чем тот же SVN, и гораздо логичнее. Я долго не мог принять, что в SVN создание ветви — делается через копирование файла. Какая-то странная логика. Затем, когда я освоил git, мне куда понятнее, что создание ветви — это создание нового узла дерева со своим parent или даже несколькими parent-ами. Обычнная иерархия, которая понятна не только программисту! Благодаря этому, очень легко прерывать проект и делать ответвления новый подверсий, работать с ними и затем, например, объединять с другими ветками. Git — это как бы мощный diff с элементами иерархии (diff хорошоф знаком тем, кто работает с Unix).

Что нужно четко понимать в git?

Отличительная идеология git от многих других программ контроля версий — наличие index. Index — это «промежуточный слой» между вашим рабочим файловым деревом, и того, что должно быть добавлено в репозитарий. В репозитарий добавляется только то, что есть в индексе. А в индекс вы добавляете из рабочего дерева то, что необходимо добавить затем в репозитарий. Запутано, скажете вы? Когда вы начнете работать, вы поймете, что это очень даже логично! Именно эта «фишка» git поначалу у меня вызывала непонимание.

Ветвление — одна из замечательных свойств git-а. Ветвить можно не просто разные версии программ, а даже по «мелочи». Например, вы хотите добавить новую фичу в программу. Если вы начнете работать на текущей стабильной версии, вы рискуете создать ситуацию, когда в рабочей версии будет найден баг, вам надо будет быстро его исправить, а вы не закончили и не отладили проект с вашей новой фичей. Тем самым, попадете в затруднительную ситуацию. Выход из нее простой — создали подветку, делаете свою новую фичу. Если необходимо, вы можете быстро переключаться между ветками. Ветвление в git — не ресурсоемкий процесс. Им удобно пользоваться и даже нужно. Иначе использование git превратится в стрельбу из пушки по воробьям.

Также, сразу постарайтесь приучить себя к такому способу ведения проекта в git, как активное использование масок для игнорирования файлов. То есть, вы ведете проект, но в нем есть два типа файлов и директорий — условно назовем служебные и проектные. Служебные  — те, что создаются в процессе работы и нужны только для компиляции. Проектные — те, что должны отслеживаться git-ом, лежать в репозитарии, и являться частью проекта в целом. Служебные должны исключаться через файл .gitignore (man gitignore). Приучите себя сразу формировать этот файл, от рождения проекта, и постепенно, по мере работы, добавлять в него новые и новые файлы и маски. Этот файл также упростит вам жизнь с командами add & status.

Также, при групповой работе надо знать, что git — не локирует файлы на время редактирования кем либо. Один и тот же файл могут править несколько программистов. Принцип тут такой — если изменения происходили в «далеких» местах друг от друга в файле, git их объединит автоматом, если же нет — будет создан конфликт, требующий ручного исправления кем либо.

Еще несколько понятий и терминов.

Commit - это как бы фиксация изменений. Коммит имеет запись в истории — кто создал, когда, одну или несколько строк от автора изменений, что сделано. Также, можете просто предствавить — что commit — как бы снимок всей директории и файлов на тот момент.

Diff - текстовые отличия в формате diff между ветками, commit-ами, файлами и т.п.. Формат его легко читаем и даже сразу понятен, если посмотреть на него — вы видите, что добавляли или удаляли и когда.

Merge - объединение веток. Благодаря иерархии (что из чего следовало) и инструментам нахождения отличий (diff), git сам определяет, что было добавлено в код, что удалено, и на основе этих изменений он делает новые файлы в объединении. Но иногда может случиться так, что один и тот же файл в близких местах менялся в разных ветках. Вот тогда возникает конфликт (см. ниже)

Conflict - конфликт. Если вы делали merge, и при этом возникли противоречия, git создает «конфликт». Эта ситуация, когда файл с конфликтом помечается внутри базы git особым образом, в самом текстовом коде возникают текстовые метки типа ‘<<<<’ или ‘>>>>>>’ с кодами из обоих веток и от вас требуется ручное редактирование файла — устранение конфликта. Вам надо посмотреть эти метки в самом коде, решить, что правильнее, отредактировать, а потом дать понять git-у, что файл вы привели в норму (git add …). С бинарными файлами несколько иначе, но смысл тот же.

Repository - репозитарий, то есть хранилище. Как уже говорил, любая копия может юыть репозитарием одновременно для кого либо. Вы можете сами для себя определить, где будет главная копия. Закачку и выкачку лучше всего осуществлять через ssh протокол. Делается просто — там где лежит репозитарий, он должен лежать под правами, скажем пользователя user. Тогда, чтобы вытянуть от туда, вам надо знать либо пароль user, либо иметь ssh ключ. А сама выкачка делается также просто, без всяких ssh команд: «git clone user@therehost.com:git/myproject.git», например. А дальше, git запомнит адрес репозитария, и обмен данными превратится в две простые команды: «git push» и «git pull». Если еще правильно организовать доступ по ssh ключам, то можно вообще не вводить пароли
Также, маленький нюанс — репозитарий может быть двух типов: bare и обычный. Обычный — это файловое дерево проекта + .git служебная директория, где все и хранится git-овское. А bare — это только файлы .git — там нет рабочей директории, и bare используется только для репозитариев с целью сохранения и взятия информации их них. Обычно, bare репозитариям дают суффикс ‘.git’. В остальном — работа синхронизации идентична.

Если вы поставили git на Unix, то все по нему можно узнать из man-ов: «man git», или, например: «man git-diff» и т.п.. Все в нем делается через одну команду — git, а вторым параметром указывается сама команда. А сам «мен» по ней состоит из git и через дефис той команды, что вам нужна (список всех команд — man git).

Также, есть Windows версия, причем, в том числе с графической поддержкой, показывающей иерархии и изменения от одного commit-а к другому. Находится она здесь: mSysGit — там выбираете, например, msysGit-fullinstall-* самый свежий и ставите. Установка проста, как и все программы для Windows. Ленивые могут использовать только графическую оболочку, а продвинутым, пожалуй, будет интересен «Git Bash» из того же комплекта. Лично я предпочитаю работать в «Git Bash», так как там привычная мощная оболочка bash со всеми ее плюсами (включая, кстати ssh-* команды).

Заключение

Не ждите волшебства от git-а. Он, конечно, не додумает за вас программный код, когда вы объединяете две ветки в одну с разным кодом в одном месте. Но сделает свою работу максимально правильно, упростив вам жизнь.

Я, как программист-одиночка, сейчас уже сложно представляю себе работу без git. Даже если проект поддерживается одним человеком, git сильно облегчает жизнь. И это не смотря на то, что все качества git-а раскрываются в групповой работе над проектом. Самым лучшим примером будет то, что ядро Linux поддерживается только через этот инструмент контроля версий. А ядро — самая динамично-развивающаяся часть кода в мире Linux — над ней работают сотни людей. А требования к ее надежности — самые высокие!