от Георги Данчев(12-12-2002)

рейтинг (1)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

Debian GNU/Linux Usefulness
(последно редактиран на 9 декември 2002)


Материалът се актуализира постепенно и затова, ако искате да следите развитието му, можете да навестявате оригиналния адрес.


I. Уточнения

Debian GNU/Linux не е току-що излязла дистрибуция, но като че ли не е достатъчно популярна особено сред новите потребители, за това този документ е предназначен предимно за тях, или за по-напреднали, които въобще не подозират какво се крие зад Debian GNU/Linux или просто for poor misguided ones.

Този документ към момента няма да стане по-изящен от стилистична или дизайнерска гледна точка - няма време, пък и е излишно май, но подобна помощ, а както и критики се приемат с удоволствие, така, че за сега е постоянно в работен вариант. Предназначен е за бързо нахвърляне на информация и особено за неща, уникални за Debian, и може би отсъстващи като фунционалност при други системи или са лошо залегнали като замисъл и/или имплементация. Също така, целта не е да се обяснява как се работи с различните utils (за това си има docs ;-), важното е да се посочи идеята и дизайнът, които са разширявани, допълвани, тествани и доказали своята гъвкавост и работоспособност през годините, а имплементацията може да се разгледа в съответните изходни кодове.  Ще се опитам да ви "удавя" (въпреки, че това е доста скромен опит ;-) с информация (или по-скоро с източници на такава), така че да предотвратя до минимум евентуално възникващи въпроси.

Ще е добре да имате Debian наоколо, инсталиран на хард диска на някоя машина, или ако нямате инсталиран Debian под ръка може да заредите на произволна x86 машина (PC) Knoppix от CDROM (без да предприемате каквито и да са интервенции по харддисковете, виж по-долу), за да е по-лесно схващането на нещата, че само с четене от този документ е доста по-трудно за разбиране.

Нека започнем с уговорката, че това изложение е направено от следната позиция (това е становище на автора, и не е задължително да се споделя от всеки):

1) Дистрибуцията трябва да бъде чиста и да пази свободата -- Social Contacts , DFSG , Free Software. Това гарантира, че ще се разработва, оценява и излага безпристрастно и само и единствено от технически аспект, без влагане на какъвто и да било друг нюанс. Така няма да можем да бъдем обвинени в недобросъвестна или неясна користна реклама. Ако трябва да бъдем честни и безмилостни към съществуващите проблеми, то първо трябва да започнем с тях, като постепенно ще се преминава към излагане на силните страни на дистрибуцията. Това гарантира, че читателят няма да бъде заблуден или оплетен още в самото начало с гръмки и сложни велики изречения, сякаш проблеми едва ли не няма. Дори се приема, че читателят, осведомен за проблемите, може да се откаже от нататъшно четене, ако е на мнение, че тези проблеми са прекалено големи за него.
2)
Дистрибуцията трябва да предоставя начин или схема за добре обмислено доставяне на софтуера (в предварително компилиран вид и като изходни кодове), който тя предлага в различните свои версии до потребителя, т.е. да е чисто installable и upgradeable, като освен това трябва да обучава потребителя кое как се прави и защо се прави по този начин, чрез съответната документация, стил и политика и изходни кодове, ако щете.

II. Проблеми

Доколко използваема от потребителите, в това число и българските разбира се, може да бъде дистрибуция като DebianGNU/Linux? Доколко българизирана е дистрибуцията?

Отговор поне на последното може да се даде веднага:  http://debian.fmi.uni-sofia.bg/~ogi/cyrillic-in-debian-woody.html , след което може да изпълните apt-cache search bulgarian за повече подробности. Подробност, която може би не всички я знаят, е, че благодарение на българите-разработчици, включени в проекта Debian, дистрибуцията е най-българизираната до момента сред всички останали. Това ще рече, че в официалния архив се поддържат пакети специално за българските потребили, които се инсталират и обновяват съвсем естествено с всички останали такива от архива, така че всичко е в синхрон, което не може да се твърди за всички останали дистрибуции, поне към момента. Това разбира се няма да "българизира" програмите, които "не разбират" от локализация и/или unicode към момента, но това е проблем на всички, който бавно, но сигурно се отстранява.

По принцип, Unix и Unix-like операционните системи не са много снизходителни към новите потребители: How to fix the Unix configuration nightmare http://www.cat.org.au/maffew/cat/unix-config.html  Забележете доколко friendly оценяват и Mac OS X, който също е branded as Unix. Доколко снизходителен към потребителите си към момента е Debian: An Unbiased Review of Debian 3.0 http://debianplanet.net/node.php?id=831

Оплаквания от объркани потренители, които в повечето случаи са основателни:
why kde and gnome's menu situation sucks http://lists.debian.org/debian-devel/2002/debian-devel-200210/thrd3.html#01391
Make Debian better http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01400.html

III. Евентуални решения и предложения за подобрения

Какво се прави или евентуално ще бъде направено за улеснение на потребителите:

3.1) Knoppix CDROM installed distribution - Това е самостоятелен проект отделно от проекта Debian, но много удобен и бърз начин човек да се запознае с GNU/Linux и в частност с доста вкултурен Debian GNU/Linux, инсталиран на CDROM, e.g. Knoppix.  Трябва ви само PC, което да може да зарежда операционна система от диск в CDROM устройството или пък ако не може да boot-ва от CDROM, да има флопи дисково устройство, за да заредите от него с boot-ващата дискета на Knoppix, която може да създадете от флопи имиджа, който е на CDROM диска. Не е необходимо да инсталирате нищо на харддиска (но при желание и това може да стане), дори може да няма и харддиск на машината.  Авторът на тази инсталирана на CDROM система ползва пакети от Debian testing/unstable, като освен това е добавил доста код е себе си за разпознаване на хардуера и решаването на задачи специфични за системи, инсталирани на read-only медия каквато е CDROM-дискът (като root filesystem се зарежда в RamDisk, т.е. в паметта, заключени потребителски акаунти и много други...,  повече обяснение за тази ОС върху CDROM на www.knoppix.org , специфичните за Knoppix сорсове, отнасящи се до разпознаването на хардуера можете да получите от http://www.knopper.net/download/knoppix/  или погледнете в /usr/src/ директорията, след като заредите от Knoppix CDROM-диска. Доста от този код на автора (ако не всичко?) е оценен като полезен и се приема в официалния Debian архив. FAQ документът ще е доста полезен включително и ако ви се наложи да си създадете boot-ваща дискета, ако машината ви не може да зареди направо от CDROM, но предполагам debian-knoppix пощенския списък може да ви дойде много.

След като заредите от Knoppix CDROM-диска, ще бъде направено опознаване на хардуера, който имате и съответно заредени необходимите драйвери, като в крайна сметка ви се стартира графична сесия (може да променяте поведението при зареждане с подаването на cheatcodes, които може да разберете с F2 когато в началото ви се подава boot: промпта). Двата акаунта (root и knoppix), с които системата идва по подразбиране са заключени, но това не е проблем. Не е нужно дори да знаете техните пароли за да ги смените, а всъщност те нямат пароли. Дори и като потребител "knoppix" имате възможността да изпълните sudo su и ставате root, след което може да му смените паролата с passwd root (тя ще е валидна само за сесията, т.е. докато рестартирате, и само вие си я знаете разбира се ;-).
Повече информация по този въпрос можете да намерите на CDROM-диска в KNOPPIX/README_Security.txt файла.

Оттук вече ако имате желание или ви се налага можете да работите със съществуващите файлови системи на харддисковете ако имате такива, да създавате нови дялове и да създавате в тях различни типове файлови системи които после да монтирате където намерите за добре и т.н. (т.е. доста мощно rescue решение). Без да инсталирате никъде нищо можете просто да прочетете документацията, специфична за Debian: man страниците на dpkg, dselect, apt, apt-get, apt-cache ..., apt.conf, apt_preferences, aptitude, sources.list, deb и т.н., както и документацията, която идва с тях в /usr/share/doc/<packagename> (packagename={apt, dpkg, dselect, aptitude и т.н.}), както и да разгледате файловете в /etc/apt/ и други.

Дори ви препоръчвам този документ да го четете от вашата Knoppix система (без да пипате нищо по харддисковете) за да поглеждате в нея, докато четете. Ако нямате възможност да си вдигнете мрежата и да четете този документ от мястото, където се хоства (т.е. от отдалечения web server), то го запишете на дискета, монтирайте я и четете от нея с браузър или текстов редактор по ваш избор ;-). След като понапреднете малко с материала и сметнете, че искате да имате инсталиран Debian на вашия харддиск (или харддискове). Можете да опитате да го инсталирате от Knoppix CDROM-диска с помоща на скрипта  /usr/local/bin/knx-hdinstall или както е описано в  Install Manual за различните хардуерни архитектури. Не бързайте с инсталацията върху харддиск, тя няма да избяга, докато разучите Knoppix-а и документацията на Debian ;-) 

3.2) More user-friendly (custom-made) Installer - доста сложна е задачата на инсталационния процес, като се има предвид броя поддържани хардуерни архитектури и начини на инсталация.

Work on the install tool http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01516.html
http://gluck.debian.org/debian-cd/ , което всъщност не е точно installer, а метод за разпространение на CD images (т.е. да на се изтегля цяло .iso, а то да се сглоби при вас чрез изтегляне на отделните файлове). Новият installer е на http://cvs.debian.org/debian-installer/

PGI - the Progeny Graphical Installer http://hackers.progeny.com/pgi/ ; http://packages.debian.org/pgi
Progeny реши да предостави Debian 3.0 Woody i386 installer images базирани на PGI 1.0.1 -- http://archive.progeny.com/progeny/pgi/ (свободен лизенз)
ISO-то съдържа само базова инсталация, като се прави hardware autodetection, и ви се предлага да изберете групи от пакети. След което може да продължите с инсталиране на пакети от външен източник (например насочвайки apt към друго Debian CD, HTTP или FTP mirror и т.н.). Ето и preview на това как изглежда началото на инсталацията с PGI 0.9.6 http://hackers.progeny.com/pgi/screenshots/

Дори можете да си създадете инсталатор по ваш вкус и желание, ползвайки кода и документацията на:
Creating Debian Installers with PGI http://hackers.progeny.com/pgi/guide.html
The Discover Hardware Detection System

http://hackers.progeny.com/discover/doc/guide.html ;

http://packages.debian.org/discover

3.3) More user-friendly desktop - според мен е достатъчно friendly. Разработена е прекрасна система за унифициране на менютата на различните графични среди, като maintainers трябва да решат какви менюта ще предоставят - upstream, debian specific, или комбинация от двете, която потребителят може да избере.

The Debian Desktop Project http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01471.html

Дори имаше и българска инициатива BG Debian за подобряване на десктопа, но идея нямам какво стана с нея:
http://linux-bg.org/cgi-bin/y/index.pl?page=news&key=344314296 ; http://debian.gabrovo.com/cgi-bin/ezmlm-cgi?iis:18:200209#b

Дотук бяха страните които обикновено плашат или притесняват особено новите потребители, които с основание биха попитали: "Ами тогава защо да ползваме подобна дистрибуция", отговорът разбира се е в т. IV, при което горните се превръщат направо в бели кахъри ;-)


IV. Управление на софтуера

4.1) Общи положения - всеобхватно, гъвкаво и надеждно управление на софтуера (binary & source), предоставян в различните версии на дистрибуцията. Нали това е грижа на дистрибуцията, наред с подръжка на fast & safe security updates, Bug Tracking System, mailing lists, new groups, irc channels ... (поправете ме ако греша ;-)

Нека като за начало да хвърлим малко светлина (ама това наистина е много набързо) към структурата на Официалния архив. Не е важно колко е актуална информацията в тази таблица (а тя не е, и едва ли има смисъл да е), важното е да се види структурата (за да не бъркаме понятията;-), която хич не е сложна и е логична (разгладейте някой официален Debian mirror за справка).

Origin

Debian

Debian

Debian

Label

Debian

Debian

Debian

Suite

Stable

Testing

Unstable

Codename

Potato

Woody

Sid

Components

main, contrib, non-free

main, contrib, non-free

main, contrib, non-free

Arch

alpha, arm, i386, m68k, powerpc, sparc

alpha, arm, i386, m68k, powerpc, sparc{64}, ia64 hppa .......

alpha, arm, i386, m68k, powerpc, sparc{64}, ia64, mips{64}...... hurd-i386 .......

Date

Mon, 16 Apr 2001

Tue, 04 Sep 2001

Tue, 04 Sep 2001

Description

Debian 2.2r3 Released 16 Apr 2001
(обновява се много рядко - само за security и point releases, e.g. revisions)

Not Released (release-ва се директно от testing, евентуално след известен период на freeze. Release Critical bugs се свеждат до минимум, защото не се допуска release с такива)

Not Released (не се release-ва директно от Unstable, тук се правят разни по-сериозни package transitions и подобни. Всичко минава първо от тук)

Version

2.2r3

-

-

MD5sum

...

...

...

По принцип горното е безкрайно ясно, но ето някои допълнителни обяснения:
*Stable, Testing и Unstable са ясни за какво са... Софтуерът влиза на http://incoming.debian.org след това в Unstable, после Testing и оттам в Stable (има и project/experimental , който е non-automatic, но това е за по-опасни експерименти). На тези Suites се присвояват кодови имена, като Unstable винаги остава с името Sid, другите се променят. Към момента Stable е Woody, Testing е Sarge, и Unstable винаги е Sid (ха да видим дали ще откриете на някой Debian mirror къде се намират съответните binary & source packages & lists files ;-). Официалният release е Stable, като освен кодово име което е имал до сега му се присвоява версия (2.1, 2.2, 3.0 и т.н.) и по-късно се правят само т.н. point releases на този release, или това са revisions (r1, r2, r3 и т.н. .....) оттук идва и това име например Potato 2.2r3 и т.н. Като се издаде нов release, старият заминава в http://archive.debian.org  като се поддържа и още известно време (разбирай security updates, etc). Между другото за security се действа по по-специален начин, най-малко вижте Security Team FAQ на  http://security.debian.org .
*Arch - освен binary builds за съответните архитектури, се предоставят и sources, които са архитектурно независи разбира се.  Естествено съответните binary packages се получават от тези source packages на машините на проекта -- http://buildd.debian.org , като потребителят също може да build от source packages.
* hurd-i386 - The Hurd е набор от програми които, работят върху микроядрото GnuMach (поне за сега само върху това микроядро и само на x86, e.g. i386) и които имплементират драйвер на файлова система, мрежови протоколи и т.н. features, които се срещат в стандартните монолитни Unix ядра (тук ще си позволя да изразя собствено мнение, че не съм против микроядрения подход, но пък съм твърд привърженик на монолитните ядра като Linux и *BSD - не мисля да обяснявам защо). За сега единственото ядро, с което се правят издания (releases) на Debian е Linux -- т.е. това е Debian GNU/Linux, с това ядро се поддържат и сървърите на проекта, които хич не са едни от най-разтоварените на света;-), но се работи и по портиране на дистрибуцията към The Hurd , който за сега стои само в Sid, работещ върху микроядро GnuMach, при което се получава Debian GNU/Hurd, следват евентуално и монолитните *BSD ядра, при което се получават Debian GNU/NetBSD, Debian GNU/FreeBSD, Debian GNU/OpenBSD (...но) за евентуално няколко хардуерни архитектури.  Всъщност погледнете и Debian on the Go (laptops) и Debian Beowulf (MPI clusters).

Както се досещатe, това, което идва от официалния архив, идва директно и се поддържа от проекта Debian  и може да бъде намерено по официалните огледални хостове, като за този софтуер освен, че се поддържат builds за всички архитектури поддържани от проекта, се възползва и от Bug Tracking System , Package Tracking System  , отчитат се Release Critical Bugs и Quality Assurance за Base и Standard и т.н. и т.н.).

Неофициалните архиви са тези, които се поддържат от любители от цял свят (като в подобни начинания могат да участват и официални debian maintainers дори for fun & tests). Структурата на подобни неофициални архиви може да наподобява тази на официалния архив напълно или частично (т.е. в най-простия случай може да е една директория с насипани вътре debian binary & source packages & list files, че дори и само binary packages, но това би било нарушение на GPL например, ако софтуерът е GPL'ed). Ето например http://www.apt-get.org е един източник, където се събират и (проверяват?) подобни неофициални източници. Подобни неофициални архиви могат да поддържат и се поддържат от проекти като KDE и т.н. Имайте предвид обаче, че обикновено се поддържа само x86 (i386) архитектурата, няма я официалната поддръжка на Bug Tracking System , Package Tracking System , дори може да няма и MD5sums на файловете и т.н., така, че вие си решавате кое да ползвате и по колко ;-)

Ето един конфигурационен файл със списък на официални и някои неофициални източници - /etc/apt/sources.list - вече трябва да сте се ориентирали как стоят нещата, и може да го ползвате, допълвайки го или коментирайки излишното. Ето ви направо и моята /etc/apt/ .....

Например: имаме /etc/apt/sources.list с редове за stable, testing, unstable и в /etc/apt/apt.conf сме указали APT::Default-Release "testing" така, че apt по подразбиране да точи от testing и само с изрично указана опция подавана на apt да се предприема теглене от stable или unstable. (ако няма указано нищо за Default-Release, apt взима най-голямата версия) ... Например:

apt-get install package1/unstable
    (т.е. само този package1 да се тегли от unstable и нищо друго... ако има неудоволетворени зависимости apt ще каже)

apt-get install -t unstable package1
    (сега вече apt има разрешение освен за package1 от unstable да вземе и неговите зависимости ако има такива пак от там)

apt-get install package1/stable package2/testing package3/unstable -s
    (малко по-сложна комбинация, при което apt ще каже дали е коректна или не... -s опцията е за симулация, т.е. ползвайте я за да проверите какво би се получило като нищо няма да бъде изтеглено и инсталирано, само за проверка)

apt-get install package1=version5
    (дори може да се конкретизира и до версия на пакет и т.н.)

Това са само няколко бързи и скромни примера, така, че маневрирайте на воля ;-) ... Имайте предвид, че състоянието на Unstable много бързо се променя, Testing също, но по-бавно, така че за кратко време влизат доста нови packages, като някой стари версии може да изпадат и т.н. Ако търсите някоя по-стара версия на даден пакет и я няма в Unstable или Testing към момента, а така също и във вашия локален cache (/var/cache/apt/archives/), но е била там преди известно време, то може да добавяте и редове към sources.list от http://snapshot.debian.org за търсене на такива по-стари и изпаднали към момента версии на отделните пакети (на сайта си пише как се ползва). А само да не объркаме някой..., мисля, че се разбира, че самата инсталация на packages се прави от dpkg (аналогично на rpm), а apt се ползва за внасяне на допълнителна логика върху всичко това и правене на по-специални магии които не са работа на dpkg да знае и може (той си има достатъчно друга работа). На него apt му подава готов набор от package(s) за обработка. Реално може да ползвате и само dpkg (точно както програмата rpm) и без надстройка като apt (или dselect), но ако има някакви неудоволетворени зависимости и/или конфликти dpkg само ще изреве, ще спре работа и ще се оплаква, докато не му ги доставите и подадете ръчно в съответния ред, вместо да даде предложения за решения и т.н. което е от компетенцията на apt (и dselect). Такива надстройки има и за rpm разбира се. Има и графични надстройки и над apt като aptitude, synaptic, gsynaptic, stormpkg, deity, gnome-apt, kpackage (последните две май са лош пример за такива;-). Нека не се бъркат програмите пакетни менажери (като dpkg и rpm) със съответните пакетни бинарни формати (.deb и .rpm), с които те работят.  Тези бинарни файлове (да речем .deb) са просто един архив (който се разпознава и от програми като ar, tar, file), които се получават от съответните сорсове (source packages, те са си .tgz или .tar.gz архив), като са конфигурирани по подходящ начин, за да се компилират и инсталират коректно на съответната система, т.е. спазва се някакъв стил и политика. Реално пакетният менажер rpm го има и в Debian, но не бива да се ползва директно за инсталиране на .rpm пакети (сложен е за създаване на такива при добро желание от страна на потребителя), най-малкото понеже тези пакети не са подходящо конфигурани и едва ли спазват стила и практиката на Debian при изготвянето на пакети, т.е. по-точно те не го спазват и това не им е работа разбира се. Има и една програмка alien която е предназначена уж за подобно конвертиране на бинарните пакетни файлове, но трябва да се убедите и разгледате какво и как конвертира, щото аз не винаги съм убеден, че го прави коректно, тъй като има maintainer scripts които едва ли се генерират при едно такова конвертиране, такива scripts просто се създават за debian source packages и са си специфични за Debian. Такива .rpm пакети са конфигурирани за съответно Red Hat, Mandrake, SuSE и т.н. (дори за съответните версии на тези дистрибуции), като хич не е добра идея .rpm пакет, конфигуриран за Red Hat, да се инсталира и особено форсирано на нещо различно от Red Hat като Mandrake, SuSE и т.н. ... Не си чупете дистрибуциите по този смешен начин, гледайки на пакетните файлове и пакетните менажери като на ябълки и круши ... ;-) Това хич не е GNU/Linux way ... Подобно поведение от страна на потребителите е лошо наследство от работата на сляпо с предишна операционна система (затворена), която лесно се обозава и плаче за преинсталация на определен период от време. Това са смешни истории (и мисля, че са безкрайно ясни) които са от далечното тъмно и затворено минало ... (no more бози;-)

Като за начало може да се прочете старият превод на български на APT-HOWTO и старият превод на български на Maint Guide (или ако имате Debian наоколо, изпълнете apt-get install apt-howto maint-guide). Силно се препоръчва четенето на Install Manual за вашата хардуерна архитектура, а както и quick-reference .


Debian може да се инсталира по много начини, както ще прочетете в наръчника за инсталация, но пък знам, че първо ще се пита за CD's. Тук разнообразието е голямо и сами можете да се запознаете от http://www.debian.org/CD/

4.2) Debian/GNU Linux: The Past, the Present and the Future -- presented at the Free Software Symposium 2002 on October 22, 2002 15:30 at the University of Tokyo.

Малко по-задълбочени сравнения и анализи: Advanced Package Management Comparations -- http://u-os.org/upm.html
Иизисква по-задълбочени познания -- аз нямам коментар (поне за сега) -- благодаря на Стоян Жеков за този ценен линк.

Като, че ли е пропуснато да се обясни малко повече за работа с debian source packages -- unique tools като auto-apt, различни проверки с dh_* (като dh_shlibdeps), създаване на local apt-repository, и подаване на custom build options глобално или per package (DEB_BUILD_OPTIONS, apt-build, apt-src, chrooted builds с pbuilder).
Това са все важни неща, като се има предвид, че потребилят в общия случай ще иска (или му се налага) да има packages от различни версии на дистрибуцията към момента (дори и доста по-стари версии на packages от http://snapshot.debian.net ), track-ването на всичко от latest (e.g. за Debian това е Sid архива, или пък non-automatic project/experimental) не винаги е разумно решение, като освен това може да е добавено и local repository или въобще unofficial repositories. Т.е. контролира се процесът на build отначалото до края ... Например auto-apt помага за откриването на липсващи headers/libs, необходими за компилацията и свързването и намирането им в кой(и) пакет(и) са и предложение за install (няма да съхраняваме камара библиотеки постоянно в системата я), подаване или установяване на custom build options, различни проверки с dh_*, особено проверка за коректност на получения binary package в който най-вероятно ще има dynamic executables които ще ползват shared libraries (soname check защото ). Подобен контрол е необходим (и ми се струва уникален Debian при builds), за да не бъде build процесът fragile, т.е. да break-ва поради липси на това и онова, особено когато се предприема на mixed environment (e.g. packages от няколко distro versions) и да има гаранции, че така полученото binary ще работи коректно (е ако има синтактични и/или логически програмни грешки в кода на приложението естествено, че или вие трябва да ги оправите или разработчиците). Така че е необходимо да има гъвкавост и потребителят да разполага с инструменти бързо и лесно да установява докъде се простира тя, и от къде нататък започват да break-ват нещата и защо. Разбира се това не пречи в /usr/local/ да водите война, ако щете инсталирайки каквото ви дойде на ума, без да омазвате нещата system-wide, пък може да пипате и там, ако се чувствате сигурни, че знаете какво правите.

New Build System for Debian. Colin Walters didn't want to wait for the dpkg maintainers to review the dpkg-source v2 code and decided to [29]address the excessive complexity and redundancy in debian/rules. He was strongly influenced by Christoph Lameter's [30]u-os package manager source format and the basic idea is to make simple things simple, and hard things possible. The code for the [31]new format is online already.

 29. http://lists.debian.org/debian-devel-0211/msg02630.html
 30. http://www.u-os.org/upm.html
 31. http://cvs.verbum.org/debian/rules

4.3) Как се изгражда дистрибуцията -- общи правила и препоръки.

Debian New Maintainers' Guide -- http://www.debian.org/doc/maint-guide/
Debian Developer's Reference    -- http://www.debian.org/doc/developers-reference/

4.4) Как се реализира контролът.

Debian Policy Manual -- http://www.debian.org/doc/debian-policy/

Ето например следващото може да е доста полезно за тези "advanced" или "power" root потребители, които обичат да компилират и инсталират system-wide, без да разбират и осъзнават какво всъщност правят и докарват своите GNU/Linux дистрибуции до състояние на омазан до безпомощност виндовс:

http://www.debian.org/doc/debian-policy/ch-files.html#s11.2
    и    http://www.debian.org/doc/debian-policy/ch-files.html#s11.3
а както и  http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Налага се да се контролират зависимостите и конфликтите при многобройните парчета софтуер, който имате в системата, особено при споделените библиотеки.
Например защо се налага и как се calculate shared library dependencies (някакъв аналог извън Debian?) ; man dpkg-shlibdeps dh_shlibdeps или опитайте http://debian.fmi.uni-sofia.bg/dwww/menu.html
За това се грижи дистрибуцията, т.е. package maintainers, но вие ако знаете повече или искате някакво more custom решение разбира се, че ще се намесите ;-

4.5) Как се конфигурира инсталираният софтуер.

The many faces of Debconf -- http://kitenet.net/programs/debconf/

man debconf debhelper (аналози извън Debian ?) и т.н. и т.н. или опитайте http://debian.fmi.uni-sofia.bg/dwww/menu.html

4.6) Some nice hints/tricks: Setting up a chroot Debian system.

The Universal Operating System as your Desktop -- http://people.debian.org/~walters/chroot.html

4.7) More: Fwd: Re: lug-bg: Gentoo ebuilds -- http://linux-bulgaria.org/lug-bg-list/archive/2002/Oct/0308.html -- Мои въпроси относно Gentoo -- мда, nice е ;-), но засега почива. Например, не предоставя механизъм за надеждното изполване на различни версии на софтуера, предлаган в различните издания на дистрибуцията, т.е. изчакваме за смислен аналог например на проверка от вида apt-get install p1/stable p2/testing p3/unstable ... p<n>/<whatever> -s ;-), тогава може да се видим пак ;-), а за Analysis of library dependencies to insure accuracy of runtime dependencies и не споменаваме; 4-5 пъти по малък архив, и горе долу толкова пъти по-малко на брой поддържани хардуерни архитектури.

Teзи, които имат желание за бесни буилди на Debian, да пообърнат внимание на apt-build, apt-src, pbuilder, auto-apt и т.н....... , спокооойно и тука има world, за да прекомпилирате софтуера, като евентуално ще бъде доинсталиран още такъв (development libraries and header files), необходим за компилцията.

Тук май е мястото да спомена, че критериите, които посочихме в началото, изпълняват и свободни операционни системи като FreeBSD, NetBSD и OpenBSD. Много добра идея ще е да се погледне и как те могат да ви бъдат от полза. Специално начинаещите потребители могат да прочетат и превода на FreeBSD Packages & Ports , въпреки че не е цялостно описание как се доставя и инсталира нов софтуер във вашата системата (т.е. визира само Third Party software), но като за начало става. Не посмях да преведа или да давам съвети как се upgrade-ва една такава система (имайки предвид всичките и части), понеже както и при Gentoo, и тук няма определен механизъм за частичен или смесен upgrade на отделни части от системата (Base & Third Party), и единствено се взима под внимание и гарантира с успех цялостен upgrade на сорсовете на системата (Warning) , или евентуален binary upgrade (не се поддържат например Conflicts, както при Debian)

Всички тези работи може би разработчиците и по-напредналите потребители ги знаят, имайки предвид резултатите от това изследване на FLOSS:
Which of the following is your favorite distribution / operating system? , но защо и по-новите потребители да не се възползват от всичко това, отърсвайки се от неправилни предубеждения и схващания, че дистрибуцията не е подходяща или не може да бъде удобна и за тях ? Напротив, дистрибуцията учи на правилно използване и прилагане на софтуера.

4.8) Битува някакво погрешно схващане (главно сред тези, които не са се докосвали до Debian), че щом операционната система се изготвя от некомерсиална организация, то това е нейн недостатък, главно поради това, че няма конкретно лице, което да поеме персонална отговорност при евентуални проблеми със софтуера. Първо, безплатна, а така и комерсиална поддръжка има (http://www.debian.org/support). Комерсиалната е ясна - лице или компания се заема с поддръжката и гарантира, че всичко ще е както сте се договорили, че трябва да бъде, и при проблеми следват някакви взаимоотношения между вас, както е навсякъде. По-важното е, че безплатната поддръжка се осъществява и идва съвсем естествено до потребителите чрез многобройните пощенски списъци, новинарски групи, пряко взаимодействие с разработчиците и т.н, и всичко това е в процеса на разработка, разбира се не всички имат времето, знанията и уменията да се възползват от всичко това -- но това е един прекрасен източник за придобиване на знанията и опита на другите, по-опитните и по-напредналите. Получава се точно обратното, главното предимство на организацията е, че е некомерсиална и съответно операционната система е такава -- т.е. изключително много се държи на техническия аспект на нещата, без влияние на каквито и да са външни странични фактори, които могат да отклонят нещата от чисто техническия нюанс. Това може би е и поради много тясната връзка с академичните среди, които се интересуват главно от техническата част на нещата. Това от своя страна води до налагане на много високо техническо ниво и задълбоченост, трудно достижимо от редица комерсиални аналози. На практика направо трябва да се погледне списъкът с регистриралите се потребители (абсолютно по своя инициатива), сред които има научни институции (изключително висока популярност), комерсиални организации, организации с идеални цели, а както и правителствени такива. Обърнете внимание на мотивите които изтъкват за ползване на системата, а както и за какви цели се ползва. Като, че ли не много комерсиални аналози биха издържали на темпото, налагано от Debian.

4.9) Обобщение - надявам се ви се поизясниха повечето от представените по-горе неща. Ето и една таблица, схематично представяща The Power of Debian:

Debianized (debian source & binary packages)

Non-Debianized
(upstream, original/plain sources)

Official  - ftp.debian.org (и mirrors)

Unofficials - www.apt-get.org

Настоящо състояние на Official

Stable


изключително консервативен release

(само fast & safe security updates  и впоследствие и point releases).

Testing


ако Stable не ви стига
точите и от тук.

(more fancy stuff..)

Unstable


ако Testing не ви стига точите и от тук.

(even more fancy stuff..)

project/experimental


с това малко по-внимателно.




(even more евентуално dangerous stuff.. )

В общия случай като структура това са частни случаи на official. Ако все пак не намирате това което ви трябва в рамките на official, преглеждате какво може да притеглите от различните unoffiial repositories. 

Изключително много рядко и трудно ще се разминете с успешен build от upstream sources (от скромност не казвам, че няма как да се разминете). Тук посочвам auto-apt който изнамира в кой debian package са необходимите и липсващи към момента в системата на потребителя headers/libs (и не само) необходими за компилацията и свързването ... Заслугата не е само на auto-apt, заслугата е на цялостния дизайн на debian packaging style който позволява това да бъде имплементирано в една такава сравнително скромна скрипт util-ка, която изглежда, че прави чудеса ...

Стари моментни състояния  на Official

Минали моментни състояния на ftp.debian.org (и mirrors)  snapshot.debian.org (snapshots на предишни състояния на official - stable, testing, unstable, project/experimental)


Забележка: ползването само на binary packages от Stable (със security updates) както се вижда от таблицата е изключително скромно и непретенциозно поведение от страна на потребителя, най-вероятно понеже потребителя не е достатъчно информиран, че има и други goodies от които може да избира и да миксира ...  така, че няма смисъл от излишна скромност, ако се налага не се стеснявайте да точите откъдето намерите и сметнете за добре...

Подобна надеждна гъвкавост и маневренност поне за сега на мен не ми е известна да съществува някъде в пределите на нашата Галактика (ето едно сравнение с нещо от real life ... )



V. Мотивация за написването и благодарности

Това е в резултат на мои лични наблюдения с течение на времето как едни или други потребители на GNU/Linux, измъчват себе си или измъчват GNU/Linux дистрибуцията, с която работят (без значение коя), при което достигнах до убеждението, че не е лошо да събирам тези неща на едно място и някога да ги приведа в по-удобен вид за четене, което може би ще им помогне да оценят с какво може или не може да им бъде полезен Debian GNU/Linux, без значение дали след това въобще и ще опитат ползването на една такава дистрибуция. Това в никакъв случай не е опит за подценяване качествата на другите дистрибуции или опит за оценяване на нещата от позицията на всезнаещ и всеможещ съдия-оценител. Напротив, като най-обикновен потребител, приемам всякакви мнения и схващания, различни от моите, от което мога да се възползвам и аз преоценявайки нещата и евентуално да се придобия чужд опит и знания (едно от хитрите неща които човек може да направи;-). От друга страна, пък е удоволствие когато след подобно представяне на дистрибуцията получавам като обратна връзка благодарности от неподозиращи силата на Debian потребители (мда случвало се е и доста по-напреднали потребители от мен да ми благодарят, че съм им обърнал внимание за съществуването на дистрибуцията, но по-голямо удоволствие е когато някой нов потребител оцени нещата и евентуално се възползва от тях, понеже по-напредналите не са за жалене, те си знаят ;-).

Специални благодарности за допълнения, корекции и разяснения на (и аз понаучих доста работи ;-):  Стоян Жеков, ...

документът е създаден и публикуван с помоща на Mozilla Composer ; Mozilla pulled and built from CVS tag  MOZILLA_1_2_1_RELEASE  ;  .mozconfig
писач danchev spnet net [препинателните знаци са ясни, да се надяваме не и за spammers]



<< Файлът XF86Config или какво се крие зад завесата | Инсталиране и настройка HTB >>