Патч (англ. patch — заплатка) — информация в виде исполняемого файла, предназначенная для автоматизированного внесения определённых изменений в файлы, из которых состоит программа. В среде программистов применение патча называется «пропатчиванием». Таким образом разработчик оставляет за собой право вносить изменения в программу для устранения проблем её функционала, исправления ошибок, повышения эргономичности и производительности, улучшения дизайна, адаптации к новой операционной среде и т.д .
Это бесплатно распространяемое программное средство, которое всегда можно найти на сайте разработчика. Поэтому процесс создания программы предполагает длительную поддержку своего программного продукта до выхода новой версии. (Слово патч встречается и в других случаях: патчкорд — сетевой кабель поключения UTP, патчпанель в СКС).
В практике программирования невозможно учесть все разнообразие условий, в которых будет функционировать программа. Проверка на «живучесть» (robustness) программного продукта — важный и обязательный этап в его разработке. История помнит скандальные зависания продуктов Microsoft во время презентаций Win 98 (Сан-Франциско, 1998) и Win8(на Тайване,2012).
Топ 10 программ которые нужны на любом компьютере. Лучшие программы для ПК
Многие производители выпускают бесплатные beta версии своих новинок для «обкатки». Действует даже система поощрений для бета-тестеров (волонтеры, которые выявляют различные багги – ошибки в программном обеспечении). Ошибки возникают не только в период тестирования, но и после её официального распространения. («Программирование похоже на секс: одна ошибка — и вам придется, потом обеспечивать поддержку на протяжении всей оставшейся жизни». Закон Мэрфи).
Но ошибки далеко не единственный повод для внесения изменений в программу. Допустим, англо-американский программный продукт оказался востребованным в арабской стране. Перед разработчиками сразу возникает задача – внести соответствующие изменения в интерфейс. Вообще-то, сейчас, когда интернет стирает все границы, разработчики программ уже заранее предусматривают возможность их использования на разных, самых популярных языках. (почему-то русский не всегда попадает в эту категорию)
Особое место патчи занимают в среде геймеров, которые активно их используют для различных, усложнений, улучшений или просто приколов. Нередко их называют Mod ами. Для этих целей используют специальные программы (Abel Loader Generator, Crayzee’s Patcher, Embryo Patcher и др). Не удивительно, когда в пропатченной версии «Counter Strike» на стене можно встретить надпись — «Здесь был Вася!» или добавляется возможность предложить раздеться за несколько долларов встречной красавице в «Duke Nukem Forever».
Многие программные продукты при установке, особенно когда «видят» подключение к интернету, предлагают пользователю подключить опцию автоматического обновления, а также получать отчеты о сбоях и ошибках. Иногда производители, даже не предупреждают о такой возможности, а по умолчанию «хозяйничают» на вашем ПК. Особенно в этом плане грешит Microsoft и Adobe. Некоторые недобросовестные производители используют патчи для продвижения других программных продуктов, не имеющих никакого отношения к улучшению или исправлению ошибок. Так при установке некоторых обновлений вы можете неожиданно обнаружить значок браузера Chrom на своем рабочем столе или целую кучу утилит от Mail.ru, от которых потом не так легко избавиться.
Как написать #patch для исполняемого файла
Перед обновлением следует отключить или настроить антивирусы и фаерволы, которые всегда «нервно» реагируют на изменение контрольной суммы файлов, или записи в системный реестр. В противном случае обновление будет установлено не корректно.
Надо ли подвергать свою программу обновлениям? Конечно надо, если вы сталкиваетесь с какими-то проблемами при её использовании.
Однозначно надо обновлять драйверы устройств, особенно видеокарты. Это напрямую связано с производительностью вашего компьютера, ноутбука или планшета. Сертифицированные патчи всегда сопровождаются текстовым файлом, содержащим краткое изложение исправлений и дополнений. Они, как правило содержат и механизм «отката»- т.е. возможность возвращения к исходному состоянию программы.
Особенно актуальны патчи для обновления программ обеспечивающих шифрование и доступ к порталам, программ бухгалтерского и статистического учета при сдачи отчетов в электронном виде.
Если работа вашей программы не доставляет вам неудобств и все вас устраивает, можете смело использовать её и без патчей и апдейтов. Так семейство операционных систем от Microsoft win7, win8 , после первой установки загружает такое количество обязательных и неважных обновлений, что понадобиться еще несколько часов, чтобы справится с этими сотнями патчей.
Не знаю, как насчёт «Здесь был Вася», но иногда патчи вносят в игры что-то действительно полезное. Например, один патч для споре позволил экспортировать сделанных в ней зверюшек как 3d-модели, мне это очень пригодилось.
Источник: www.topauthor.ru
12 ключевых вопросов об использовании патчей: важные детали, о которых нельзя забыть
Узнайте ответы на 12 ключевых вопросов о патчах: что это такое, как они работают, насколько они безопасны, какие типы патчей бывают и что стоит знать о их установке. Полезная информация для защиты ваших устройств от уязвимостей и вирусов.
Патчи – это один из способов обновлять программное обеспечение вашего устройства. Они существенно улучшают его функциональность и безопасность. Но как использовать патчи правильно, чтобы избежать возможных проблем? В этой статье мы рассмотрим 12 важных вопросов, на которые следует обратить внимание при обновлении патчей.
Раз заплатка, два заплатка: зачем нужны бинарные патчи, и как ими пользоваться
В никсах не принято использовать бинарные патчи. Обычно обновления
распространяются в виде пакетов, тарболлов с исходниками или текстовых файлов,
созданных утилитой diff. Тем не менее, настроив свою систему на обновление с
помощью бинарных патчей, ты сможешь существенно сэкономить время и трафик и даже
отказаться от перезагрузки при обновлении ядра.
В этой статье мы рассмотрим четыре механизма создания
бинарных патчей и поговорим о назначении каждого из них.
В первой части статьи я расскажу о Ksplice — технологии,
способной довести uptime сервера до 100 %, далее мы поговорим об
инструментах xdelta и bsdiff, с помощью которых можно прилично
сэкономить на трафике при обновлении системы, в третьей части
уделим внимание механизму deltup, экономия трафика при использовании которого может достигнуть 95 %. Четвертая часть посвящена
фреймворку binpatchng, предназначенному для создания пакетов с
патчами для базовой инсталляции OpenBSD в домашних условиях.
Ksplice
Наверное, о Ksplice и его недавней покупке компанией Oracle слышали все. Это такой хитрый механизм (или даже, лучше сказать, хак),
который позволяет накатывать обновления на ядро Linux на лету, не
требуя перезагрузки машины или даже какой-то работы по сборке
модулей ядра.
Принцип работы Ksplice
Механизм Ksplice использует довольно интересный метод патчинга ядра, в основе которого лежит техника изменения компонентов
ядра прямо во время его работы. Делается это в два шага. На первом
этапе отрабатывает утилита генерации бинарного патча, которая
получает на вход месторасположение исходных текстов Linux-ядра и
файл, содержащий стандартный патч на исходный код в diff-формате.
Наложив этот патч на исходники, утилита компилирует ядро, сравнивает получившийся образ с ядром предыдущей версии и генерирует
модуль ядра, содержащий измененные части, а если конкретнее — код
измененных функций. Этот патч-модуль передается на машину, ядро
которой должно быть обновлено. На втором этапе в дело вступает
модуль ядра ksplice.ko, который вместе с патч-модулем загружается
в ядро целевой машины. После загрузки ksplice.ko анализирует патч-модуль на предмет наличия новых версий функций ядра и изменяет
адреса настоящих функций ядра, так чтобы они указывали на функции, содержащиеся в патч-модуле. Таким образом удается изменить
ядро, не перекомпилируя его.
Минус такого подхода в том, что фактически он подходит только
для исправления небольших ошибок и латания дыр, более крупные
обновления, затрагивающие множество функций, добавляющие
новый функционал и изменяющие внутренние структуры ядра, таким
образом не сделаешь. Тем не менее автор Ksplice отмечает достаточно высокую эффективность системы, она смогла в полностью автоматическом режиме сгенерировать 84 % патчей для bugfix-обновлений
ядра, выпущенных за три года. Для остальных обновлений пришлось
немного поработать руками.
К сожалению, в 2009 г., после открытия компании Ksplice Inc.,
автор решил закрыть код системы, не позволив частным лицам и сторонним компаниям самим создавать Ksplice-патчи. Поэтому в этой
статье мы не будем обсуждать эту тему и рассмотрим вопрос только
с клиентской точки зрения. А выглядит она так: сегодня Ksplice
принадлежит Oracle, которая продолжает предоставлять сервис
абсолютно бесплатного онлайн-обновления ядра для дистрибутивов
Ubuntu и Fedora, а также для собственного варианта RHEL под названием Unbreakable Linux. Пользователи всех остальных корпоративных дистрибутивов пролетают.
Теперь о том, как этим пользоваться. Для Ubuntu и Fedora на сайте
ksplice.com есть пакет, его следует скачать и установить
стандартными средствами:
$ sudo apt-get install curl
$ sudo dpkg -i ksplice-uptrack.deb
Далее соглашаемся с лицензией. Появится окно со списком всех
доступных для нашего ядра обновлений. Нажимаем кнопку Install, и
система скачает нужные патчи из Сети и загрузит их в ядро. Чтобы в
случае перезагрузки патч-модули были загружены, вместе с пакетом
устанавливается стартовый скрипт. Система всегда следит за обновлениям и сообщает о них с помощью значка в трее.
xdelta, bsdiff
Итак, с Ksplice и его извращенным подходом к накладыванию патчей
разобрались, теперь настало время поговорить об утилитах, которые
позволяют применить бинарные патчи на отдельно взятые приложения. В UNIX существует как минимум три таких инструмента:
это старейшая разработка xdelta, выросшая из куска кода rsync,
отвечающего за инкрементальный бэкап, его более современная и
развитая версия под названием xdelta3 и bsdiff, разработанные для
использования в BSD-системах.
По своей сути все три инструмента представляют собой аналог
всем нам известной программы diff, который оперирует не строками,
а последовательностью байт. Это дает возможность использовать
утилиты не только для вычисления разницы между файлами с
исходным кодом, но и для любых других данных, будь то бинарник
приложения, tar.gz-архив или даже видеофайл. Если тебе интересно,
как это работает, то рекомендую ознакомиться со статьей «Дельта-кодирование», опубликованной
в Wikipedia, я же лучше расскажу о том, зачем всё это
нужно и как с этим работать.
Для чего нужен бинарный diff? Всё очень просто: имея возможность накладывать бинарные патчи на уже работающие приложения
или целые архивы с исходниками, можно серьезно сэкономить на
трафике. В нашем безлимитном мире экономия трафика может и не
сделать большой выгоды в денежном плане, но вот время сократит существенно,
особенно при крупных обновлениях всей системы. Некоторые дистрибутивы позволяют
«встроить» утилиты для накладывания бинарных патчей в пакетный менеджер, так что, исправив
всего пару-тройку конфигов, можно просто сидеть и наслаждаться
быстрыми апдейтами.
Для того чтобы механизм инкрементальных апдейтов заработал,
должно быть выполнено три условия. Во-первых, пакетный менеджер дистрибутива должен поддерживать работу с утилитой инкрементального апдейта. Такая поддержка есть в pacman из ArchLinux
и через установку дополнительного пакета debdelta, в Debian.
Во-вторых, должен существовать специальный delta-репозиторий,
который будет отвечать за хранение патчей к пакетам и своевременно генерировать новые патчи для обновлений. Такие серверы обычно
держат энтузиасты, поэтому обычно их довольно трудно найти, а если
найдешь, никто не даст гарантии, что завтра сервер не исчезнет (это
главная беда бинарных патчей). И в-третьих, в кэше пакетного менеджера всегда должны лежать закэшированные во время предыдущей установки пакеты, на которые как раз и будут накладываться
патчи. Это важный момент, так как многие из нас (и я в том числе)
любят время от времени этот кэш подчищать (однако для debdelta, о
котором мы поговорим ниже, и они не нужны).
Теперь о том, как происходит настройка пакетного менеджера:
В ArchLinux всё решается довольно просто. Устанавливаем третью
версию xdelta:
$ sudo pacman -S xdelta3
Открываем /etc/pacman.conf, снимаем знак комментария со
строки UseDelta. Открываем список репозиториев /etc/pacman.d/mirrorlist и в самое его начало добавляем следующую строку:
Сохраняем файл и пробуем выполнить полное обновление дистрибутива:
$ sudo pacman -Syu
Разница должна быть, что называется, налицо. Проблема только в
том, что archlinux.fr содержит дельты далеко не для всех пакетов, но,
увы, альтернативы здесь просто нет.
В Debian это делается несколько иначе. Существует специальная
утилита (а точнее, набор утилит) под названием debdelta, которая
умеет разбирать deb-пакеты по косточкам, вычислять разницу между
файлами двух версий пакетов с помощью xdelta и генерировать
новый пакет на основании этих данных. При накатывании патчей это
чудо использует уже установленные в систему пакеты, а потому не
требует хранения старых версий пакетов в кэше apt-get. Проблема
только в том, что debdelta никак не интегрируется с apt-get, а поэтому
его надо вызывать вручную перед каждым обновлением системы:
$ sudo apt-get update
$ sudo debdelta-upgrade
$ sudo apt-get upgrade
Зато не нужно никакой настройки и возни с репозиториями
(официальный репозиторий успешно работает уже многие годы). Сам
debdelta устанавливается так:
$ sudo apt-get install debdelta
Стоит сказать о том, что BSD-аналог xdelta под названием
bsdiff также имеет большое применение. Он
был написан для утилиты обновления системы freebsd-update и стал
частью базовой установки FreeBSD в 2005 г. Каждый раз, когда ты делаешь «freebsd-update install», в дело вступает bsdiff (а точнее, его
часть bspatch), который прозрачно обновляет систему с помощью бинарных патчей. Благодаря BSD-лицензии, разрешающей включать
код в закрытые приложения, bsdiff получил большое распространение и за пределами BSD.
deltup
Интересную альтернативу бинарным патчам предложил в свое время
один из поклонников дистрибутива, Gentoo. Он создал утилиту
deltup, которая брала два архива с исходниками разных
версий приложения, распаковывала их, генерировала патч с помощью
стандартного diff, упаковывала его и снабжала информацией, нужной
для получения не отличимого от оригинала архива с одной версией
приложения из архива с другой. Говоря простым языком, deltup-файлом
можно пропатчить тарболл старой версии программы, чтобы получить
тарболл с ее новой версией, избежав необходимости в загрузке всего
тарболла. Результаты работы утилиты оказались просто поразительными: средний размер deltup-патча составляет всего 15 % от размера
оригинального архива, а зачастую и 5 % (с этими цифрами можно ознакомиться на
странице статистики головного deltup-сервера).
Сегодня поддержка deltup в Gentoo есть из коробки, также необходимый инструментарий был портирован во FreeBSD. Существует
несколько более или менее стабильно работающих серверов, отвечающих за генерацию и отдачу deltup-патчей. Настройка, опять же,
совсем не сложна:
В Gentoo порядок действий следующий. Устанавливаем инструменты deltup и getdelta:
$ sudo emerge deltup getdelta
Добавляем в /etc/make.conf следующую строку:
Так мы сообщим emerge о том, что хотим использовать команду
getdelta для получения архивов с исходниками. Далее открываем
конфигурационный файл /etc/deltup/getdelta.rc и пишем туда следующее:
$ sudo vi /etc/deltup/getdelta.rc
# Адрес локального репозитория (если есть)
LOCAL_MIRROR=1.2.3.4
# Максимальная позиция в очереди на ожидание дельты
MAXIMUM_ACCEPTABLE_QUEUEPOS=10
# Удалять старые версии файлов
REMOVE_OLD=yes
Опцию LOCAL_MIRROR можно не добавлять, она нужна только в том
случае, если в локалке есть Gentoo-репозиторий, который можно использовать вместо запроса патча от deltup-сервера. Опция MAXIMUM_ACCEPTABLE_QUEUEPOS задает максимальную позицию в очереди на
создание дельты. Большинство deltup-серверов генерируют дельты
во время первого обращения клиента за архивом, поэтому очередь за
особо тяжеловесными приложениями и последними обновлениями
может выстроиться большая. Нет каких-то определенных рекомендаций по поводу размера очереди, так как нагрузка на сервер может
быть разной и время, которое ты можешь прождать, — тоже. Самостоятельно указывать какой-либо deltup-сервер не требуется, сегодня все
серверы подключены к linux01.gwdg.de, который вписан в getdelta по
умолчанию.
Это всё, при следующем обновлении пакета ты должен заметить
разницу во времени скачивания.
Порт deltup есть и для FreeBSD. Он не требует своего собственного
репозитория и может использовать deltup-сервера Gentoo (все-таки
исходники приложения для разных платформ одни и те же). Чтобы
научить систему портов FreeBSD использовать deltup для обновления софта, необходимо сделать следующее:
1. Установить deltup и wget из портов:
$ cd /usr/ports/sysutils/deltup
$ sudo make install clean
$ cd /usr/ports/ftp/wget
$ sudo make install clean
2. Добавить в файл /etc/make.conf следующую строку:
$ sudo vi /etc/make.conf
FETCH_CMD=/usr/local/bin/getdelta.sh
Теперь независимо от того, используешь ли ты систему портов напрямую или различные фронт-энды типа portupgrade, обновления будут происходить с помощью deltup-сервера. Однако необходимо быть
готовым к тому, что иногда deltup ошибается и собирает не совсем
точную копию архива, которая вполне нормально распаковывается,
но имеет неправильную контрольную сумму (это следствие микроразличий в разных версиях gzip и bzip2). В этом случае сборку пакета
можно осуществить, добавив предписание NO_CHECKSUM:
$ cd /usr/ports/games/cowsay
$ make NO_CHECKSUM install clean
Шпаргалка по бинарным патчам
$ bsdiff старый_файл новый_файл файл_патча
$ bspatch старый_файл новый_файл файл_патча
$ xdelta3 -e -s старый_файл новый_файл файл_патча
$ xdelta3 -d -s старый_файл файл_патча новый_файл
$ deltup -mjb 9 старый_файл новый_файл файл_патча
$ deltup -p файл_патча
$ debdelta старый_файл новый_файл файл_патча
$ debpatch -A файл_патча / новый_файл
OpenBSD Binpatch
Еще один инструмент, о котором я бы хотел рассказать в этом обзоре,
не имеет отношения к бинарным патчам как таковым, но будет интересен и полезен владельцам компов, работающих под управлением
операционной системы OpenBSD.
Все, кто имеет хоть малейшее представление о процессе выпуска
релизов и заплаток для OpenBSD, знают, насколько он самобытен и
прост. При выпуске релизов разработчики скорее ориентируются на
план, чем на накопление достаточного количества важных изменений. После выпуска новой версии ОС сразу начинается работа над
следующей, а все ошибки и баги, найденные в это время, фиксятся с
помощью заплаток, которые каждый пользователь/админ должен
скачать, наложить на исходный код и пересобрать его. Делать это
не только жутко неудобно, но порой просто не представляется возможным. Многие железки под управлением OpenBSD не обладают
достаточной мощностью и дисковым пространством, для того чтобы
содержать в себе всё дерево исходных текстов OpenBSD, компилятор,
линковщик и промежуточные результаты компиляции. Но даже если
всё это на железке есть, но сама железка при этом не единственная
в подчинении, однотипные действия придется выполнять несколько
раз, что тоже не слишком интересно.
Чтобы решить эти проблемы,был придуман фреймворк
binpatch, позволяющий скачивать патчи, накладывать их на исходный код, собирать
пропатченное приложение или ядро и помещать его в архив в полуавтоматическом режиме. Позднее появилась модификация фреймворка под названием
binpatchng, которая
позволяла упаковывать пропатченные приложения не только в
архив, но и в пакет OpenBSD-формата, да так, что при удалении этого
пакета система откатывалась в первоначальное состояние.
Binpatchng полностью основан на Makefile’ах и концептуально
очень близок к системе портов. Чтобы создать новый патч, необходимо прописать в нужный Makefile пару простых правил, описывающих патч и способ его сборки, а затем выполнить команду make. Всё
остальное система возьмет на себя и вскоре сгенерирует готовый
к установке архив или пакет, который достаточно скопировать на
нужную машину и установить с помощью стандартных средств.
На
пальцах всё это выглядит следующим образом:
1. Скачиваем фреймворк и распаковываем его в каталог /usr
(на самом деле можно и в другое место):
$ cd /tmp; wget http://goo.gl/hvF7O
$ su
# tar -xzf /tmp/binpatchng-1.1.tar.gz -C /usr
2. Скачиваем архивы sys.tar.gz и src.tar.gz с официального FTP
и помещаем их в каталог distfiles, внутри binpatchng:
# cd /usr/binpatchng-1.1/
# mkdir distfi les
# cd distfi les
# wget ftp://ftp.openbsd.org/pub/OpenBSD/4.9/sys.tar.gz
# wget ftp://ftp.openbsd.org/pub/OpenBSD/4.9/src.tar.gz
3. Скачиваем инсталляционные архивы для нужной архитектуры
(например ftp://ftp.openbsd.org/pub/OpenBSD/4.9/i386/) и помещаем
их в distfiles/имя_архитектуры.
4. Пишем Makefile. Для этого переходим на страницу
www.openbsd.org/errata.html, выбираем нужный релиз (для 4.9 пока патчей нет, поэтому я
возьму за пример 4.8), выбираем интересующий нас патч (например 001_bgpd.patch), открываем его. В первой строке будет указан способ сборки
патча. Наша задача — переложить его на язык Makefile. Это просто:
создаем файл /usr/binpatchng-1.1/Makefile и пишем в него следующее:
# vi /usr/binpatchng-1.1/Makefi le
# Для какой архитектуры собираем? (Можно не указывать,
# если совпадает с архитектурой текущей машины.)
ARCH=i386
# Здесь перечисляем патчи (просто откидываем расширение patch)
PATCH_COMMON=001_bgpd
# Здесь идут инструкции для сборки патча 001_bgpd.patch
001_bgpd:
cd $/usr.sbin/bgpd
($; $; $)
# Далее можно поместить инструкции по сборке остальных патчей…
Правим binpatch Makefile
Самое сложное в этом файле — это инструкции сборки, они могут
показаться мудреными, однако написать их очень легко. Достаточно
просто перевести описанные в официальном патче инструкции на
макроопределения. Например, в нашем случае они выглядели так:
cd usr.sbin/bgpd
make obj
make depend
make
make install
Сравни их с директивами в Makefile, и всё поймешь. За дополнительными подробностями обращайся к примеру, описанному в файле
Makefile.sample. Теперь можно собрать пакет с нужным патчем:
# cd /usr/binpatchng-1.1/
# make PATCH=»001″ build
# make PATCH=»001″ plist
# make PATCH=»001″ package
Пакет с результатом должен появиться в каталоге patches, его следует
скопировать на нужную машину и установить с помощью такой команды:
# pkg_add binpatch-4.9-i386-001.tgz z
INFO
Debdelta имеет
опцию ‘—delta-algo’,
с помощью которой
можно указать предпочитаемую утилиту для создания
патчей. Доступные
варианты: xdelta,
xdelta-bzip, xdelta3
и bsdiff.
Работу по написанию Makefile
для binpatchng
можно полностью
автоматизировать,
если воспользоваться скриптом,
опубликованным
в дискуссионном
листе OpenBSD.
Источник: xakep.ru