Начало Вход/Регистрация Помощ Tazi stranica s latinski bukwi
Области
 Новини
 Актуална тема
 Linux портали
 Какво е Линукс?
 Въпроси-отговори
 Форуми
   •Трудова борса
   •Конкурс
 Статии
 Дистрибуции
   •Поръчка на CD
 Made In BG
 Файлове
 Връзки
 Галерия
 Конференции
Настройки
 Външен вид
 Предложения
 Направи си сам
И още ...
 За нас
 Линукс за българи ЕООД
 Линк към нас
 Предложения

Подкрепяно от:
TelePoint - Място за хора със свободни идеи

SiteGround

initLab

Adsys Group

SAP Bulgaria

Дистрибуции

Foresight Linux  
Име:                     Foresight Linux
Сайт:                    http://www.foresightlinux.org/
Текуща версия:     2.5.3+2013.03
Производител:      The Foresight Linux Project


<< Fedora | FreeBSD >>

Повече информация  

Внимание: Тази статия се нуждае от актуализиране.

Foresight е линукс дистрибуция насочена главно към десктоп потребителите с някои специфични (положителни) особености:

Първо малко предистория, тази дистрибуция се базира почти изцяло (като идеология) на rPath Linux, друга дистрибуция, която всъщност разработва и реализира пакетния менажер използван от Foresight (наречен conary) и за чиито характеристики ще стане дума по-нататък.
Тук трябва да спомена защо представям Foresight Linux вместо неговият по-голям брат rPath Linux.
Причината е проста, rPath Linux (като дистрибуция) е доста стар, и май не се обновява активно, версиите на пакетите в последната му версия са стари. Той служи по-скоро като "демонстрация на работеща функционалност" (в случая на conary) и база за създаване и работа на нови дистрибуции (на база conary). Така всъщност се постига и една от основните цели и и се използват предимствата заложени при проектирането на conary (виж по-долу).

Основната част от екипа, разработил rPath са хора активно работили преди това в RedHat, затова и много от нещата са взаимствани/наследени от RH/Fedora дистрибуцията - init система, начини за настройка и т.н.

Предговор
Концепцията на която се базира conary има за цел избягване на някои от недостатъците на класическите пакетни системи ('rpm' и 'dpkg'), като освен това се добавят нови функции, които (засега) не присъстват в реализацията на друг пакетен менажер. Това според създателите се налага поради бързото развитие на Интернет и разрастването на хората/общностите създаващи "Отворен код".

Първо да спомена за недостатъците на класическите пакетни менажери, които conary цели да избегне/коригира:

1. Създаването на разклонения (Branching) - традиционните пакетни системи използват номер на версията за да обозначат (идентифицират) пакетите като "стари" и "нови". В допълнение към това се използват и някои други концепции (като "epochs") за да се избегнат проблемите при номера на версии които не следват конвенциите на дадената пакетна система.
Простата наглед концепция "стар" "нов" не работи добре когато има много на брой и силно разклонени клонове на разработка.
Например една и съща версия на изходния код служи за създаване на многобройни бинарни версии дори за различни базови версии на дадена дистрибуция. Простото линейно сортиране по номера на версиите не може точно да представи подобна ситуация, тъй като никоя от тези версии не е "по-нова", те просто за предназначени за различен контекст (i386, i586, i686, athlon-xp или пък fc, mdk и т.н.).
2. Ограничения на пакетните хранилища - традиционните пакетни системи не осигуряват възможности за съвместна координирана работа между отделни (относително независими) хранилища. Хранилищата понякога съдържат пакети с конфликт на версиите, рядко може да се стигне дори до конфликт на имена. Засега начина за избягването на тези конфликти е в допълнителните означения за 'дистрибуция' и базова версия на дистрибуцията - например: fc3-i386 или mdk-i586 и suse92 (тук липсва версия за архитектурата).
Въпреки че това грубо казано върши работа, то често води потребителите (особено начинаещите) до объркване и оттам до грешки.
Освен това тези конвенции не са стандартни и унифицирани като спазването им е въпрос само на добра воля.
Програмите за автоматично намиране и инсталация на нови/обновени пакети донякъде помагат, но при наличието на все повече хранилища, проблема става все по-очевиден.
Един пример (без скорошен личен опит) е несъвместимостта между хранилищата на Debian и Ubuntu пакети (дори за Debian-unstable и последната версия на Ubuntu). Същото с още по-голяма сила важи за "rpm" пакетите (където много често се прилагат и съвсем различни пачове).
3. Изходния код е разделен от бинарните пакети - при традиционните пакетни системи изходният код не е тясно свързан със съответните му бинарните пакети. Бинарният пакет често включва 'подсказка' за това кой пакет с изходен код е използван за създаването му, но не съществува формална връзка между двата.
Много хранилища съхраняват само най-новите версии на пакетите, така че дори да се знае от кое хранилище е взет пакета, може да се случи да не може да се свали изходният код на пакета, тъй като той вече е премахнат от хранилището или обновен към по-нова версия. Този проблем може да се реши, но за това също не съществува официална съгласувана политика между дистрибуциите (съответно хранилищата).
4. Наименуването е случайно и неуправлявано - не съществува общ уникален механизъм за наименуване (на пакетите) с цел избягване конфликтите на имена, версии и release номера. Избягването на подобни конфликти става само посредством конвенции и е успешно само когато обхвата му е ограничен. От това страдат "пакетните-зависимости", те са валидни само в рамките на една дистрибуция и нямат глобална валидност.
Например два пакета (от Fedora и SuSE) за "iptables-1.2.8" (без допълнителните означения) инсталирани по грешка на грешната дистрибуция най-вероятно ще я "счупят" (ако въобще се инсталират).
В допълнение към горното съществува доста "грубо" разделение за "архитектура" (i386, i486, i586, i686, x86_64 и др.), което не предлага всички реално съществуващи възможности, тук се включват и използваните глобални и локални (за пакет) флагове/опции. Ако пък се създадат повече варианти това силно ще затрудни идентификацията на пакетите и управлението на хранилищата. Тук нещата пак се решават с неформални конвенции, но някои специфични опции/оптимизации изискват като единствено решение компилиране от изходен код.
5. "Крехки" скриптове - класическите пакетни системи позволяват да се добавят към пакетите скриптове (като мета-данни). Те най-често се изпълняват в резултат на някакво действие, като инсталация, изтриване, преконфигуриране. Този подход създава някои проблеми:
- грешки в скриптовете често води до катастрофа и изисква сложни гимнастики в следващите версии. Това също така понякога ограничава възможността да се върнем към по-стара версия (която има грешка в даден скрипт);
- повечето такива скриптове са "шаблони", които просто се копират от пакет на пакет. Това увеличава вероятността от грешка (нова грешка при копиране или пренасяне на стари грешки в новия пакет);
- "Тригери" - (скриптове в един пакет, които обаче се изпълняват в резултат от действие в друг пакет) внасят нива на сложност, които често възпрепятстват всякакви усилия за "контрол на качеството" (QA).
- скриптовете не могат (е трудно) да бъдат променени с оглед покриване на някакви специфични изисквания на локалния компютър;
- скриптове предназначени за една дистрибуция често се провалят, когато се инсталират (поради грешка) на друга дистрибуция.

Сега след като добре "оплюх" най-разпространените пакетни менажери, мисля да напиша и как (си мислят че) решават тези и други проблеми създателите на conary.
Това което четете по-горе е синтез (превод) на документи на rPath и Foresight, но държа да подчертая че те до голяма степен се покриват и с моето мнение, минали и настоящи наблюдения (на етап четиридневна работа и доста четене), така че това не е само още един орязан превод ;)

Сега идва ред и за предимствата на Foresight (съответно conary):

Въведение в Conary

Conary осигурява оригинален подход при управлението на приложения с отворен код, включва нови идеи за разпределено управление и конфигуриране подобни на тези в GNU arch и monotone. Вместо да се концентрира върху управлението на отделни пакети, както 'rpm' и 'dpkg' conary използва мрежово-достъпни хранилища, съдържащи структурирана по версии йерархична информация за всички файлове и групи от файлове в дадена дистрибуция.

Този нов подход осигурява няколко вълнуващи нови възможности:
- можете да създавате, поддържате и разпространявате промени чрез създаване на нови клонове на разработка и второ има възможност за следене на промените в съществуващи вече клонове като в същото време запазвате и в тях локално направените промени. Тук освен лесно разклоняване има и възможност за "лесно" връщане към базовия клон;
- интелигентно се запазват локално направените промени в Вашата система. Едно обновяване няма "сляпо" да премахне локално направените промени;
- можете да дублирате локално направените на една машина промени, като ги инсталирате и на други машини, така улеснявайки поддръжката на множество машини;
- както и доста други приятни изненади (както ще видите по-надолу).

Сега започвам поред с кратко описание на новите възможности:

А.Разпределено дърво с версии.

А.1.Хранилище - всичко се съхранява в мрежово-достъпно разпределено хранилище, реализирано като мрежово-достъпна база данни (SQlite, и като опция MySQL).
А.2.Файлове - съхраняването на файловете (в хранилището) става чрез уникален идентификатор а не чрез тяхното име, така името става част от метаданните и може дори да се променя, както и всички други атрибути (собственик, права, време, съдържание и т.н.)
А.3.Troves, Packages and Components - пакетите са съставени от компоненти, които от своя страна съдържат файлове. Trove се наричат и пакетите и компонентите, trove е множество от файлове или от други troves.
Конпонентите са удобни тъй като съдържат различни части на даден пакет, някои стандартни означение (суфикси) за компоненти са:
:source, :runtime, :lib, :devel, :docs и т.н. Само да спомена че всички *:source компоненти не са част от никой пакет, тъй като някои от тях се използват при създаването на повече от един пакет (отделно се пести и място).
А.4.Етикети и Версии - използват се доста по дълги стрингове за да се описват имената и мястото на произход, като обаче тази информация (обикновенно) се скрива и се съкращава до нещо като: 2.2.3-4-2, което е по-лесно за разбиране. Тук 2.2.3 е номера на оригиналната версия на пакета, 4 е номера на последния release на изходния код, a 2 e число, показващо броя на генерираните от този изх. код бинарни пакети. Само за пример ето едно пълно "име" на пакет: /conary.rpath.com@rpl:trunk/2.2.3-4-2. Тук съзнателно съкращавам доста информация.
А.5.Сенки (shadows) - тази функция осигурява възможност да се правят и съхраняват локалните промени (създаване на собствен "клон"). Тук също съзнателно съкращавам доста дългото иначе описание.
А.6.Характеристики (flavors) - тази пък функция позволява много подробна настройка на опциите за определяне на "архитектури", "променени конфигурации" и "използвани флагове" (както глобални така и специфични за даден пакет).

В.Разлики/Промени (changesets) - conary използва разлики когато инсталира нови приложения, тоест свалят се и се записват на локалната файлова система само променените неща за даден пакет. Това спестява трафик, място (в хранилището) и не презаписва (съхранява) направените локани промени (най-често конфигурации и др.).
В.1.Представяне на локалните промени - можете да генерирате "локални промени", които са относителните разлики между съдържанието на локалната система и същата информация от хранилището (на база пакет). След това можете да го "приложите" и върху други машини или пък да го направите част от разклонение на локалното/някое хранилище. При втория начин можете да обновявате и чрез това хранилище.
В.2.Обновяване (merging) - При актуализация на даден пакет това става чрез 'three-way merge' между 'оригиналния инсталиран файл'<->'файла от локалната файлова система'<->'версия на същия файл която ще бъде инсталирана'. Същото се отнася и до правата за достъп на файловете.
Доста рядко, но е възможно да се получи конфликт между локалната и новата версии, тогава е необходима ръчно да се разреши конфликта. С цел съвместимост за създаване/прилагане на разликите се използват "diff/patch".
В.3.Ефективност - следват някои причини за по-високата ефективност в сравнение с традиционните пакетни системи:
- използването на "промени" спестява трафик и време за пренасяне;
- прилагането само на промените ускорява инсталацията, особено за големи пакети с малки (по обем) промени;
- спестява се място в хранилището тъй като в него се съхранява само едно копие на даден обект (файл);
- чрез използване на "разпределени хранилища" е възможно: да се спести време за поддръжка на променено копие на цяло хранилище и се пести място необходимо за съхраняване на цялото хранилище.
В.4.Връщане към старо състояние (rollback) - като слествие от използването на "промени" при обновяване на системата (които се съхраняват по версии) е много лесно да се направи връщане към произволно избрано предходно състояние. Логично това връщане може да стане само "стъпка-по-стъпка" чрез прилагане на "промените" в обратен ред. Не може да скочите директно към дадено състояние. Частично ршение на горното ограничение е че след това можете отново да обновите само тези пакети които желаете.

С.Други концепции
С.1.Динамични тагове - това е частта от conary, която решава проблема с "крехките скриптове". Съвсем накратко "динамичните тагове" са описатели за различните типове данни/код (elf, library, info и т.н.). Какво общо има това със скриптовете? Оказва се че има, към всеки "динамичен таг" може да се прикрепи/насочи един тъй наречен "tag handler", който в общия случай е скрипт който се изпълнява за всички файлове от този "tag". Това е в основни линии.
С.2.Групи и набори файлове - тук ще си спестя малко писане, като само кажа че групите са нещо подобно на "групите пакети" в Debian (и производните), както и в rpm-производните дистрибуции. Тоест при инсталация или по-късно казване "искам десктоп система" и т.н.
Наборите файлове са предназначени основно за изгращдане на малки (embedded) системи - рутери, контролери и др., като описват само даден набор от файлове.

D.Бъдеща работа - дистрибуцията (пакетния менажер) е относително зряла (средна възраст), като обаче conary (списъка с разпределени хранилища) все още се развиват и доработват, така че има място за действие ;)

Заключение - Лично аз вече използвам тази дистрибуция (то пък оставаше и да не я ползвам, но да го напиша) и вероятно ще остане (заедно с Gentoo).

Още отсега оставям място и за недостатъците на Foresight (conary) а те освен това и реално съществуват. Определено не искам да Ви заблуждавам ;)

Недостатъци:
1.Conary се разпространява под "свободен лиценз", но някои други части (за да си направиш собствена дистрибуция - Builder) са затворени. Може да има и други подобни неща; 2.Ползването на външни хранилища улеснява, но заедно с това и ограничава, особено ако цялата информация е налична само в в едно от тях (conary.rpath.com@rpl:trunk);
3.Друг (относителен) минус е факта че Foresight е насочена главно към най-новата версия на Gnome и външно е оформен за работа основно като декстоп система. Това по-тясно насочване води до значително по-малко разнообразие на всякакви приложение (сървърни и други). Примерно някои от пакетите с които обикновенно работя (и съответно познавам по-добре) ги няма, например - djbdns (има bind), qmail (има postfix)и т.н.
Това обаче може донякъде да се обясни с броя на разработчиците (около 12), така че това си е техен избор и проект, пък и все още остава възможността за инсталиране от изх. код ;) дори в собствен клон на разработка.
Това ограничение обаче не е твърдо, ако някой/и направи/ят хранилище съдържащо пакети с KDE, XFCE, други отделни приложение, няма да е проблем да се ползват,при това в рамките на същия пакетен менажер.
4.Днес (8.02.2013) отново погледнах XFCE-2.5.2 версията(12.2011) и определено може да се каже че е направена главно за десктоп ползване-много малко са включените приложения (другите трябва сам да си ги компилираш и инсталираш), не е особено трудно, но е специфично.
5.Други - засега остава празно ...

Вече е налична за сваляне последната версия на Foresight/URL:
http://www.foresightlinux.com/downloads

Приемам всякакви отзиви/коментари ;)

Последна редакция: 07-ное-2014



Редактори на тази секция са Rumen_Yotov, TheArch

Коментар от: pe6o oaxa (a) abv< dot >bg Дата: 29-05-2009
[ Други коментари]
iponiatie si niamam koe kak stava

<< Към: не работещи връзки

Коментари: (общо 9) Оценени с или повече [Пълен преглед>>]
[Добави коментар]

Вашият коментар
Име:
E-Mail: (по желание)
Заглавие:
Е ОТГОВОР НА ТОЗИ КОМЕНТАР(ДА)


Описание: ?

Внимание: Допълнителна проверка при коментари от нерегистрирани потребители.

МЕНЮ
Търсене

ЛОГО

КАТЕГОРИИ
Adamantix
Annvix
Arch Linux
Astaro Security Linux
Aurox
Bodhi Linux
Crux
Damn Small
Debian GNU/Linux
Fedora
Foresight Linux
FreeBSD
FreeSco
Gentoo
Gnoppix
Knoppix
Linux Mint
Lunar-Linux
Mageia
Mandrake
MandrakeMove
Mandriva
Minix
MoviX
NetBSD
OpenBSD
PCLinuxOS
Red Hat
Salix OS
Sidux
Slackware
SLAX
Source Mage GNU/Linux
StotinkaOS
OpenSUSE
Тиликс
Ubuntu
ULTILEX
Учи Свободен с Убунту (УСУ)
Vector Linux
VS Live
VS Live Mini CD

ВРЪЗКИ
Дистрибуции в България
DistroWatch
Още дистрибуции





 
© 2011-... Асоциация "Линукс за българи"
© 2007-2010 Линукс за българи ЕООД
© 1999-2006 Slavej Karadjov
Ако искате да препечатате или цитирате информация от този сайт прочетете първо това
Външния вид е направен от MOMCHE
Code Version: 1.0.8 H (Revision: 23-09-2011)
 
Изпълнението отне: 0 wallclock secs ( 0.24 usr + 0.03 sys = 0.27 CPU)