\chapter{Анализи, оценки, предложения} Малко по-задълбочени сравнения и анализи има в \hlink{Advanced Package Management Comparisons}{http://u-os.org/upm.html}. Debian/GNU Linux: \hlink{The Past, the Present and the Future}{http://u-os.org/tokyo.html} --- presented at the Free Software Symposium 2002 on October 22, 2002 15:30 at the University of Tokyo. Като, че ли е пропуснато да се обясни малко повече за работа с debian source packages (FIXME: да се обясни още по-подробно): \begin{itemize} \item уникални инструменти като \deb{auto-apt}, различни проверки с \texttt{dh\_*}, като \texttt{dh\_shlibdeps}, или направо проверете какво съдържат пакетите \deb{dpkg-dev} и \deb{debhelper}, разгледайте сорса и документацията на съответните програми, идващи с тях. \item създаване на \textit{local apt repository}, и подаване на \textit{custom build options} глобално или поотделно за пакет (\texttt{DEB\_BUILD\_OPTIONS}, \deb{apt-build}, \deb{apt-src}, chrooted builds с \deb{pbuilder}). Това са все важни неща, като се има предвид, че потребителя в общия случай ще иска (или му се налага) да има пакети с различни версии на дистрибуцията към момента. Може да са нужни и доста по-стари версии на пакети от \hlink{http://snapshot.debian.net}{http://snapshot.debian.net}, както и следене на последните версии на всичко (за Debian това е Sid архива или пък \texttt{project/experimental}. Това не винаги е разумно решение, като освен това може да е добавено и local repository или въобще unofficial repositories, т.е. контролира се процеса на build от началото до края. Например \deb{auto-apt} помага за: \begin{itemize} \item откриването на липсващи хедъри и библиотеки, необходими за компилацията, свързването и намирането им в кой(и) пакет(и) са и предложение за инсталиране \item подаване или установяване на \textit{custom build options} \item различни проверки с \texttt{dh\_*}, особено проверка за коректност на получения \textit{binary package}, в който най-вероятно ще има програми, които ще ползват поделени библиотеки (soname check и \hlink{Debian Library Packaging guide}{http://www.netfort.gr.jp/\textasciitilde% dancer/column/libpkg-guide/libpkg-guide.html\#AEN29} \end{itemize} Подобен контрол е необходим и ми се струва уникален Debian при builds, за да не бъде build процеса "`чуплив"', т.е. да прекъсва поради липси на това и онова, особено когато се предприема в смесена среда (напр. пакети от няколко издания на дистрибуцията). Трябва да има гаранции, че така полученото binary ще работи коректно. Ако има синтактични и/или логически програмни грешки в кода на приложението, естествено, че или вие трябва да ги оправите, или разработчиците. Така че е необходимо да има гъвкавост и потребителят да разполага с инструменти бързо и лесно да установява докъде се простира тя и от къде нататък започват да че чупят нещата и защо. Разбира се, това не пречи в \texttt{/usr/local/} да водите война, инсталирайки каквото ви дойде на ума, без да разваляте нещата system-wide, пък може да пипате и там, ако се чувствате сигурни, че знаете какво правите. \end{itemize} Нова система за \textit{build} на пакети се готви от Colin Walters. Тя се нарича \hlink{версия 2}{http://lists.debian.org/debian-devel-0211/msg02630.html} на source пакетите и в нея се адресират сложността на сегашните \texttt{debian/rules} файлове, както и многото излишък в тях. Новата система е силно повлияна от \hlink{\textit{u-os} пакетната система}{http://www.u-os.org/upm.html} на Christoph Lameter. Основната идея е да се направят нещата прости, a сложните неща --- възможни. В тази връзка доста се спекулира с т.н. source-based distributions, като Gentoo, при които софтуерът се компилира направо на машината на потребителя. Естествено, това може да стане и с debian source packages, въпреки че малко потребители го знаят;-). Основната идея е, че така могат да се използват по-добре оптимизациите на компилатора за съответния процесор. В това има доза истина, обаче се отнася само до т.н. CPU-intensive приложения като аудио и видео плеъри, библиотеки в които са реализирани някакви тежки математически или криптографски алгоритми, въобще програми, които могат да се възползват от конкретните за дадения процесор инструкции. Може да се окаже дори, че разликата между процесорите от x86 архитектурата не е забележима, докато при процесорите от Sparc архитектурата например едно такова оптимизиране дава сериозно отражение върху производителността. Затова не е лошо някои CPU-intensive приложения да се прекомпилират на място и да се оптимизират от source packages, ebuilds, ports и т.н., но да се очаква, че всички приложения ще се възползват от едно такова оптимизиране, е меко казано несериозно. Тук са замесени възможностите на съответното CPU, възможностите на съответния компилатор да оптимизира за него, както и самият на приложениетоу което се опитваме да оптимизираме. Ако последното е много зле, то никакъв компилатор и оптимизатор не може да ви помогне, затова най-добре се оптимизаира от изходния код на самото приложение. \hlink{Ето едно сравнение на Debian за i386, Mandrake за i586 и Gentoo}{http://articles.linmagau.org/modules.php?op=modload\&name=Sections\&file=index\&req=viewarticle\&artid=227\&page=1}. Или с казано накратко, подобни оптимизации са определящи от гледана точка на производителността в много специфични случаи и не е казано, че само source-based distros могат да компилират своите пакети на потребителската машина. Debian предлага впечатляващо много инструменти по въпроса, като доста от тях са разгледани в предните глави на тази книга. Вече като малко по-напреднали трябва да четете: \begin{itemize} \item \hlink{Maint Guide}{http://www.debian.org/doc/maint-guide/} или \hlink{стария превод на български}{http://debian.gabrovo.com/docs/maint-guide/index.html} \item \hlink{Debian Developer's Reference}{http://www.debian.org/doc/developers-reference/} \item \hlink{Debian Policy Manual}{http://www.debian.org/doc/debian-policy/} \item и въобще \hlink{Debian Developers' Corner}{http://www.debian.org/devel/} \end{itemize} \chapter{More} \hlink{Fwd: Re: lug-bg: Gentoo ebuilds}{http://linux-bulgaria.org/lug-bg-list/archive/2002/Oct/0308.html} Не предоставя механизъм за надеждното изполване на различни версии на софтуера предлаган в различните издания на дистрибуцията, т.е. изчакваме, например, за смислен аналог на проверка от вида \begin{verbatim} # apt-get install p1/stable p2/testing p3/unstable \end{verbatim} За Analysis of library dependencies to insure accuracy of runtime dependencies и не споменаваме; 4--5 пъти по малък архив и горе долу толкова пъти по-малко на брой поддържани хардуерни архитектури. Teзи, които имат желание за собствени биулдове на Debian, да обърнат внимание на \deb{apt-build}, \deb{apt-src}, \deb{pbuilder}, \deb{auto-apt} и т.н. Тук май е мястото да спомена, че критериите, които посочихме в началото, изпълняват и свободни операционни системи като \hlink{FreeBSD}{http://www.freebsd.org}, \hlink{NetBSD}{http://www.netbsd.org} и \hlink{OpenBSD}{http://www.openbsd.org}. Много добра идея ще е да се погледне и как те могат да ви бъдат от полза. Специално начинаещите потребители могат да прочетат и превода на \hlink{FreeBSD Packages \& Ports Collection}{http://www.freebsd-bg.org/html-br-up/}, въпреки че не е цялостно описание как се доставя и инсталира нов софтуер във вашата системата, а визира само Third Party software, но като за начало става. Не посмях да преведа или да давам съвети как се upgrade-ва една такава система (имайки предвид всичките й части), понеже както и при Gentoo, и тук няма определен механизъм за частичен или смесен upgrade на отделни части от системата (Base and Third Party) и единствено се взима под внимание и гарантира с успех цялостен upgrade на сорсовете на системата (вижте \hlink{Synchronizing Your Source}{http://www.freebsd.org/doc/en\_US.ISO8859-1/books/handbook/synching.html}) или евентуален binary upgrade (не се поддържат, например няма \texttt{Conflicts}, както при Debian). Всички тези работи може би разработчиците и по-напредналите потребители ги знаят, имайки предвид статистиката за \hlink{Which of the following is your favorite distribution / operating system?}{http://floss1.infonomics.nl/floss1/stats\_13.html} от окончателното изследване и проучване \hlink{FLOSS}{http://www.infonomics.nl/FLOSS/report/} на Международния Институт по Информатика към Университета на Маастрихт (Холандия) в партньорство с Berlecon Research, Berlin и Proactive International ( Paris). Данните са приети от \hlink{European Commision}{http://www.europa.eu.int/comm/index\_en.htm}. Та защо и по-новите потребители да не се възползват от всичко това, освобождавайки се от неправилни предубеждения и схващания, че дистрибуцията не е подходяща или не може да бъде удобна и за тях? Напротив, дистрибуцията учи на правилно използване и прилагане на софтуера.