Что такое форк в программировании

Что такое форк в программировании

У разработчиков есть понятие «форк» — оно часто встречается в командной разработке и в проектах с открытым кодом. Посмотрите, что это, и когда вам предложат сделать форк, вы будете во всеоружии.

Пример: игра в дурака

Игра в дурака — одна из самых простых карточных игр. У всех на старте по 6 карт, есть колода, есть козырные карты, все ходят по очереди и подкидывают друг другу карты, чтобы самому остаться без карт.

Но в разных компаниях принято играть в дурака по-разному:

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

И ещё десяток разных вариантов в зависимости от компании или от того, как принято в этом месте.

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

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

�� Форк — это новая программа на базе какой-то версии исходной программы. Она может дальше развиваться самостоятельно, без оглядки на исходную программу.

Откуда такое название

Форк в переводе с английского — это вилка, развилка или ответвление (fork). Этот термин стали использовать, потому что ручка вилки — это как будто основная программа, а зубцы — ответвления от неё. Чтобы было понятнее, вот картинка с форками игры в дурака.

Каждое ответвление — это своя отдельная версия игры, которая живёт и развивается по своим правилам. А вместе все эти ответвления напоминают вилку — отсюда и название.

Если есть время, посмотрите ветку форков Линукса в википедии. Предупреждаем: она большая и это надолго.

Форки в программировании

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

1. У программы исходный код находится под лицензией, которая разрешает свободное использование и копирование этого кода, в том числе создание форков.
2. Есть разработчики, которые готовы вкладывать в этот проект время и силы. Если просто форкнуть исходный проект, но ничего с ним не делать, он так и останется замороженной и устаревшей версией, которой никто не пользуется.

�� Чтобы форк был успешным, в него тоже нужно вкладывать много времени и сил, как в основной продукт. Если им не заниматься, форк умрёт. Та же судьба ждёт форк, если им никто не будет пользоваться — в конце концов чаще всего разработчикам надоедает поддерживать софт просто так и они его забрасывают.

Примеры форков

В современном мире многие успешные сервисы, продукты и программы — это форки. Смотрите сами:

• Движок WebKit (используется в Safari) — это форк движка KHTML из рабочей среды KDE для Линукса.
• Вордпресс — форк b2/CafeLog.
• OpenOffice — форк СтарОфиса, а LibreOffice — это форк ОпенОфиса.
• Веб-сервер Апач — форк NCSA HTTPd.
• Microsoft SQL Server — форк Sybase SQL Server.
• Половина криптовалют — это форки исходного алгоритма биткоина в разных вариантах.

А вот ещё интересный случай, как бывает с форками. Сначала была библиотека node.js, потом от неё пошёл форк io.js, а в 2015 году этот форк стал официальным node.js.

Зачем нужны форки

Причин может быть много:

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

�� Главная причина появления форков — желание сделать лучше. Но обычно получается не лучше, а просто по-другому.

Форк и версии

Иногда форк путают с версиями, хотя у них есть важное отличие:

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

Как сделать свой форк

1. Скопировать себе исходный код или нажать кнопку Fork в проекте на гитхабе.
2. Назвать его как угодно.
3. Пожалеть об этом, потому что теперь вы в ответе за собственный софт, который нужно развивать.

Fork на GitHub — что это такое

Продолжаю увлекательное знакомство новичка с сервисом GitHub и с системой контроля версий Git.

Так как имею учетную запись на GitHub, которую регулярно использую, то у меня возник вопрос, который не мог не возникнуть, рано или поздно. Касается он такой темы, как fork.

Не знаю даже, как правильно поступить дальше — попытаться самому описать вопрос, своими словами; или же попытаться сделать вольный перевод статьи на эту тему — Fork A Repo. Но лучше все же расскажу своими словами.

Fork — это копия репозитория

Fork — это вcего навсего копия репозитория. Это тоже самое, что branch в Git. Только на GitHub такой branch называется

fork

— присутствует своя терминология. Само слово fork в переводе означает ответвление. Для того, чтобы воспользоваться

fork

, нужно иметь свою собственную учетную запись на GitHub; и нужно войти под ней на GitHub в момент выполнения

fork

fork

? Для тех же целей, что и branch в Git. С помощью него создается точная копия оригинального репозитория, только на сервисе GitHub. В копии репозитория можно вносить свои собственные изменения, редактировать файлы или удалять директории.

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

pull request

Если авторам оригинального репозитория ваши изменения понравятся, то они могут внести их в свой собственый оригинальный репозиторий — принять запрос и выполнить слияние.

Существование fork полностью отвечает идеологии OpenSource и GitHub, в частности. Идеология OpenSource заключается в свободном обмене исходным кодом программ и fork однозначно помогает в этом деле. С помощью fork можно одним движением получить копию любого исходного кода, выложенного на GitHub в свободном доступе.

Fork — создание копии репозитория

Давайте от слов перейдем к делу и на практике выполним хотя бы один fork на GitHub. К слову сказать, в приведенной выше статье-оригинале Fork A Repo дается ссылка на репозиторий Spoon-Knife, созданный авторами статьи для учебных целей — научиться работать с fork на GitHub. Вы, уважаемый читатель, также можете свободно воспользоваться им для себя, чтобы научиться пользоваться fork.

Я воспользуюсь другим репозиторием, который выложен в свободном доступе достаточно известным верстальщиком Юрием Артюхом (akella). Ниже привожу шаги по созданию Fork на GitHub.

• захожу на GitHub под своей учетной записью
• перехожу по ссылке github/akella/sass, по которой расположен репозиторий akella/sass

Фактически, теперь я нахожусь в репозитории akella/sass пользователя akella (Юрий Артюх). Об этом красноречиво говорит надпись akella/sass в левом верхнем углу окна браузера. В правом верхнем углу окна браузера нахожу кнопку Fork.

И нажимаю на нее:

Может случиться, что вы, уважаемый читатель, ничего и не заметите. Но это не так на самом деле. Приглядитесь к “главной” надписи — она изменилась с

Что такое форк в программировании

Next: Запуск процессов с помощью Up: Процессы Previous: Таблица процессов Contents

Для порождения процессов в ОС Linux существует два способа. Один из них позволяет полностью заменить другой процесс, без замены среды выполнения. Другим способом можно создать новый процесс с помощью системного вызова fork() . Синтаксис вызова следующий:

#include #include pid_t fork(void);

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

• идентификатора процесса (PID, PPID);
• израсходованного времени ЦП (оно обнуляется);
• сигналов процесса-родителя, требующих ответа;
• блокированных файлов (record locking).

Процесс-потомок и процесс-родитель получают разные коды возврата после вызова fork() . Процесс-родитель получает идентификатор (PID) потомка. Если это значение будет отрицательным, следовательно при порождении процесса произошла ошибка. Процесс-потомок получает в качестве кода возврата значение 0, если вызов fork() оказался успешным.

Таким образом, можно проверить, был ли создан новый процесс:

switch(ret=fork()) < case -1: /при вызове fork() возникла ошибка/ case 0 : /это код потомка/ default : /это код родительского процесса/ >

Пример порождения процесса через fork() приведен ниже:

#include #include #include #include #include #include main() < pid_t pid; int rv; switch(pid=fork()) < case -1: perror("fork"); /* произошла ошибка */ exit(1); /*выход из родительского процесса*/ case 0: printf(" CHILD: Это процесс-потомок!\n"); printf(" CHILD: Мой PID -- %d\n", getpid()); printf(" CHILD: PID моего родителя -- %d\n", getppid()); printf(" CHILD: Введите мой код возврата (как можно меньше):"); scanf(" %d"); printf(" CHILD: Выход!\n"); exit(rv); default: printf("PARENT: Это процесс-родитель!\n"); printf("PARENT: Мой PID -- %d\n", getpid()); printf("PARENT: PID моего потомка %d\n",pid); printf("PARENT: Я жду, пока потомок не вызовет exit(). \n"); wait(); printf("PARENT: Код возврата потомка:%d\n", WEXITSTATUS(rv)); printf("PARENT: Выход!\n"); >>

Когда потомок вызывает exit() , код возврата передается родителю, который ожидает его, вызывая wait() . WEXITSTATUS() представляет собой макрос, который получает фактический код возврата потомка из вызова wait() .

Функция wait() ждет завершения первого из всех возможных потомков родительского процесса. Иногда необходимо точно определить, какой из потомков должен завершиться. Для этого используется вызов waitpid() с соответствующим PID потомка в качестве аргумента. Еще один момент, на который следует обратить внимание при анализе примера, это то, что и родитель, и потомок используют переменную rv . Это не означает, что переменная разделена между процессами. Каждый процесс содержит собственные копии всех переменных.

Рассмотрим следующий пример:

#include #include #include int main() < char pid<[>255; fork(); fork(); fork(); sprintf(pid, "PID : %d\n",getpid()); write(STDOUT_FILENO, pid, strlen(pid)); exit(0); >

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

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

Fork (разработка программного обеспечения) — Fork (software development)

Новая программа и направление разработки программного обеспечения, основанное на существующей Временная шкала того, как Дистрибутивы Linux разветвляются.

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

Бесплатное программное обеспечение с открытым исходным кодом, которое по определению, может быть получен от исходной команды разработчиков без предварительного разрешения и без нарушения закона об авторских правах. Однако также встречаются лицензионные форки проприетарного программного обеспечения (например, Unix ).

• 1 Этимология
• 2 Формирование бесплатного программного обеспечения с открытым исходным кодом
• 3 Формирование проприетарного программного обеспечения
• 4 См. Также
• 5 Ссылки
• 6 Внешние ссылки

Этимология

Слово «вилка» использовалось для обозначения «разделять на ветви, идти разными путями» еще в 14 веке. В программной среде это слово вызывает системный вызов fork, в результате которого выполняющийся процесс разделяется на две (почти) идентичные копии, которые (обычно) расходятся для выполнения разных задач.

В контексте разработки программного обеспечения «вилка» использовалась в смысле создания элемента управления версиями «ветвь » Эриком Аллманом еще в 1980 году в контексте SCCS :

Создание ветки «разветвляется» на версию программы.

Этот термин использовался в Usenet к 1983 году для процесса создания подгруппы для перемещения тем обсуждения.

Неизвестно, что термин «вилка» использовался в смысле раскола сообщества во время зарождения Lucid Emacs (ныне XEmacs ) (1991) или BSD (1993–1994); Расс Нельсон использовал термин «раскол» для такого рода вилок в 1993 году, приписывая его Джону Гилмору. Однако «вилка» использовалась в настоящем смысле к 1995 году для описания разделения XEmacs, а к 1996 году была понятным использованием в проекте GNU.

Разветвление свободного и открытого — исходное программное обеспечение

Бесплатное программное обеспечение и программное обеспечение с открытым исходным кодом может быть законно разветвлено без предварительного согласия тех, кто в настоящее время разрабатывает, управляет или распространяет программное обеспечение в соответствии с Определением свободного программного обеспечения и Открытым Определение источника :

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

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

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

Эрик С. Реймонд в своем эссе Homesteading the Noosphere заявил, что «наиболее важной характеристикой форка является то, что он порождает конкурирующие проекты, которые не могут впоследствии обмениваться кодом, разделяя потенциального разработчика сообщество «. Он отмечает в Жаргонном файле :

Разветвление считается плохим делом — не только потому, что оно подразумевает много потраченных впустую усилий в будущем, но потому, что вилки, как правило, сопровождаются большим количеством раздоров и ненависти между группы преемников по вопросам легитимности, преемственности и направления дизайна. Существует серьезное социальное давление против разветвления. В результате основные форки (такие как Gnu-Emacs / XEmacs разделились, разделение группы 386BSD на три дочерних проекта и короткое- жилого раскола GCC / EGCS) достаточно редки, чтобы их помнят индивидуально в хакерском фольклоре.

Дэвид А. Уилер отмечает четыре возможных исхода вилки с примерами:

1. Смерть вилки. Это, безусловно, самый распространенный случай. Легко объявить вилку, но приложить значительные усилия для продолжения независимой разработки и поддержки.
2. Повторное слияние вилки (например, egcs становится «благословенным» в качестве новой версии gcc.)
3. Смерть оригинала (например, X.Org Server успешно и XFree86 умирает.)
4. Успешное ветвление, обычно с дифференциацией ( Например, инструменты OpenBSD и NetBSD.)

Распределенный контроль версий (DVCS) популяризировали менее эмоциональное использование термина «вилка», стирая различие с «ветвью». DVCS, например Mercurial или Git, обычный способ внести свой вклад в проект — это сначала создать личную ветвь репозитория, независимую от основного репозитория, а затем попытаться получить ваши изменения интегрированы с ним. Такие сайты, как GitHub, Bitbucket и Launchpad, предоставляют бесплатный хостинг DVCS, явно поддерживающий независимые ветви, такие как технические, социальные и финансовые барьеры раздвоить кислый Репозиторий кода ce значительно сокращен, и GitHub использует термин «вилка» для обозначения этого метода участия в проекте.

Форки часто перезапускают нумерацию версий с 0.1 или 1.0, даже если исходное программное обеспечение было версии 3.0, 4.0 или 5.0. Исключение составляют случаи, когда разветвленное программное обеспечение предназначено для замены исходного проекта, например MariaDB для MySQL или LibreOffice для OpenOffice.org.

Создание проприетарного программного обеспечения

В проприетарном программном обеспечении, авторские права обычно принадлежат организации-работодателю, а не отдельным разработчикам программного обеспечения. Таким образом, проприетарный код чаще всего разветвляется, когда владельцу необходимо разработать две или более версий, таких как оконная версия и версия командной строки, или версии для разных операционных систем, например текстовый процессор для IBM PC совместимых машин и Macintosh компьютеров. Как правило, такие внутренние вилки будут сосредоточены на том, чтобы иметь одинаковый внешний вид, поведение, формат данных и поведение между платформами, так что пользователь, знакомый с одной, также может работать продуктивно или обмениваться документами, созданными на другой. Это почти всегда экономическое решение для увеличения доли рынка и, таким образом, окупаемости связанных дополнительных затрат на разработку, связанных с форком.

Заметным проприетарным форком не такого рода является множество разновидностей проприетарного Unix — почти все, производные от ATT Unix по лицензии и все называемые «Unix», но все более взаимно несовместимые. См. Войны UNIX.

Лицензии BSD позволяют форкам стать проприетарным программным обеспечением, а сторонники авторского лева говорят, что коммерческие стимулы, таким образом, делают частную собственность почти неизбежной. (Однако лицензии с авторским левом можно обойти с помощью двойного лицензирования с проприетарным грантом в форме лицензионного соглашения с участником.) Примеры включают macOS (на основе проприетарного NeXTSTEP и открытый исходный код FreeBSD ), Cedega и CrossOver (проприетарные вилки Wine, хотя CrossOver отслеживает Wine и вносит свой вклад значительно), EnterpriseDB (ответвление PostgreSQL, добавляющее функции совместимости с Oracle), поддерживаемый PostgreSQL с их собственной системой хранения ESM и проприетарная высокомасштабируемая производная PostgreSQL от Netezza. Некоторые из этих поставщиков вносят изменения в проект сообщества, в то время как некоторые сохраняют свои изменения как свои собственные конкурентные преимущества.

См. Также

• Список программных вилок
• Исходный порт
• Нисходящий поток (разработка программного обеспечения)
• Групповое принятие решений
• Модульное программирование
  • Моддинг
  • Повторяющийся код

  Ссылки

  Внешние ссылки

  • Право на вилку на Meatball Wiki
  • Доктор философии изучение разветвления: (Найман, 2015) «Понимание разветвления кода в программном обеспечении с открытым исходным кодом — изучение разветвления кода, его влияние на ПО с открытым исходным кодом, а также то, как оно рассматривается и практикуется разработчиками»
  Похожие публикации:

  1. Cache module status degraded hp proliant что это
  2. Как в телеграмме сделать чек сбербанка
  3. Как отменить выделение в excel
  4. Почему не работает margin 0 auto