Ликбез: о пакетах и их значении в народном хозяйстве

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

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

Под Windows и MacOS компилированием занимаются в основном те, кто программы пишет — Windows (либо MacOS) у всех худо-бедно одинаковый, архитектура компьютеров — всё та же старая IA-32, более известная как x86 (или PowerPC, для старых Маков). Правда, для появившейся в последнее время 64-битной версии Windows приходится компилировать отдельно, но это уже детали. К тому же большинство авторов программ для Windows и MacOS очень не хотят, чтобы исходный (на понятном языке) код их программ кто-нибудь увидел, модифицировал и использовал в своих целях, а обратный компиляции процесс (дизассемблирование) — не самое простое дело.

Для систем с открытым кодом (GNU/Hurd, GNU/Linux, *BSD и иже с ними) компиляция программы конечным пользователем куда более традиционна. Связано это с тем, что та же Linux может работать на огромном количестве архитектур, от ARM до Big Endian, а исходный код большиства программ открыт для чтения и модификации всем желающим, так что куда проще распространять программу именно в виде исходного кода (исходников, или «сырцов», от «source»), и на месте компилировать с учётом конкретной системы и архитектуры процессора.

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

Есть и ещё один момент: поскольку исходники открыты, большинство программ используют общие библиотеки функций (в самом деле, какой смысл писать свой код для опроса, к примеру, клавиатуры, если этот код уже кем-то написан — в крайнем случае можно дописать нужную функцию в уже готовую библиотеку). Сами программы становятся меньше и компактнее (программистам под Windows, не имеющим возможности пользоваться кусками чужих программ, приходится писать лишний код), большинство программ используют одни и те же библиотеки — красота. Однако при установке программы выясняется, что она для работы требует библиотеку A, которая требует библиотеки B и C, которые в свою очередь… Поди разберись, что из этого уже есть в системе, а что надо скачать и установить — но система управления пакетами берёт все эти заботы на себя, автоматически скачивая пакеты с недостающими библиотеками…

Короче говоря, система управления пакетами ­— это наше всё! Можно, конечно, если понадобилась новая программа, найти и скачать из Сети сырцы, а потом скомпилировать; можно искать в сети бинарный пакет, качать и устанавливать его самому… Но куда проще запустить любимый менеджер пакетов, вбить в окошко поиска название нужной программы и пойти заваривать чай — система сама найдёт нужные пакеты в репозиториях, всё скачает, установит и будет следить за обновлениями.

Вот, в общем-то, и всё на сегодня о пакетах. Разве что добавить ещё, что на сегодняшний день в мире Linux существует две основных системы управления пакетами: RPM (RedHat Package Manager), которая используется собственно RedHat, Fedora, SuSE, Mandriva, PCLinuxOS, ASPLinux и множеством других дистрибутивов, и APT (Advanced Packaging Tool), созданная в своё время для Debian и используемая в Debian и её производных (Ubuntu, Xandros и т. д.), а также OpenSolaris. Кроме этого есть система портов, используемая в Gentoo, но Gentoo — это вообще очень отдельный разговор…