Изпечатай

[yasnv]

Знам че въпросът е доста "необичаен",ще приема и едно евентуално изтриване на темата(ако модераторите сметнат за необходимо).

Става въпрос за това,че колкото повече дистрота пробвам "повече се обърквам".Например не мога да разбера каква е разликата ПРИМЕРНО между Дебиан и Слакуеър.Не ми казвайте че единия използва .deb файлове а пък за другия има .rpm такива.На Слак-а като му сложиш slapt-get и става почти Дебиан пък и .rpm с една много проста команда става .deb.Така и двете ОС сами решават проблема с зависимостите.Някак си излиза че и на яве всичко е еднакво '> (говоря за package managment като цяло).Е?

Много е възможно да имам грешни разбирания,но в момента съм объркан.Ако щете разглеждайте въпроса и като "каква е философията на двете дистрота"?

Всяко мнение ще ми бъде от полза.Казвайте каквото мислите и дано стане добра дискусия

[taiko]

Как пък приши на Слак-а RPM-та?!?!?!

[yasnv]

да,възможно е да греша обаче имам спомени да съм срещал.
Пък и да съм сгрешил смисъла въпроса не се променя.

[CyberBoy]

Сложи си Debian, после сложи Slack. Ако не усетиш разликата сам никой няма да може да ти помогне '>
Slackware е с .tgz пакети. Това, че може да си сложиш rpm и да работиш с такива пакети не означава, че това е дефолт пакетната система. Колкото до slapt-get, неможе да се сравнява по никакъв начин с apt-get.
Аз ползвам Slackware. Ти си реши кво да ползваш.

[n_antonov]

Абе, разлики няма. Важното е да рулира

[mhydra]

Лошото е това че Слак умира.
Погледнете другите дистрибуции и Слак и можете да забележите че всички друстибуции вървят напред и изпреварват Слака.
Дори новопоявили се дистрибуции предлагат доста добра производителност и стабилност като Слак.
Просто Слак не се развива с необходимата бързина и причината че се прави от един човек. А не голяма корпорация като Ред Хат примерно.

Вижте един Arch линукс как за отрицателно време направиха неща които в Слак още липсват. Като добра пакетна система с зависимости и добро управление. Плюс това броят на пакетите на Слак е доста по-малък от тези на Дебиан или Федора или пък СуСЕ.

Докато Слак се прави от един човек, то той няма да е конкурентен на другите дистрибуции.
Защо казвам че е не е конкурентен ли?
Ами на запад коя корпорация ползва за техни сървъри Слак?
Никой, всички ползват Ред Хат/Федора или Дебиан.

[souldead]

Слак не умира, има хиляди хора които ползват слак и никога няма да го заменят за друга дистрибуция(като мен). Просто в момента няма много ъпдейти защото на Пат му се роди дъщеричка. Разликата освен в пакетната система(която в слак може да се каже че отсъства) е и в стартиращите скриптовеи и в идеологията. Слака се придържа максималко към юникс, или поне така беше едно време. пусни инсталация на бсд и на слак и открий 10-те разлики. като цяло на пакетните системи най-много мразя сложните зависимости и разбитите на хиляди малки пакетчета продукти. Слака си има прости пакети в които си пише кой какви библиотеки иска, но не е нужно да се съобразяваш с тях. В слак имаш пълен контрол над всичко и е с немодифициран кернел, идва почти гола система и ти я модифицираш по свой образ и подобие ако меразбирате какво искам да кажа.

[martos]

Цитат

Дори новопоявили се дистрибуции предлагат доста добра производителност и стабилност като Слак.

Аргументи някакви имаш ли за това. Нещо не съм забелязал подобно нещо, а пък имам два десктопа и пет сървъра с него

[Lord Bad]

Между Слак и Дебиан разликите са от земята до небето - като почнем от пакетната система, продължим със инициализационната система, цикъла на разработка, официално включените пакети и акцентите в системата. И двете са топ дистрибуции безспорно, но никак, никак не си приличат доколкото може да не си приличат две GNU/Linux системи де'> Иначе за общите неща - и двете са i386 оптимизирани, и в двете bleeding edge софт рядко се появява...

Цитат (mhydra @ Ян. 25 2006,09:41)

....които в Слак още липсват. Като добра пакетна система с зависимости и добро управление. Плюс това броят на пакетите на Слак е доста по-малък от тези на Дебиан или Федора или пък СуСЕ...

mhydra, ще те включа в  любимата ми група на "БРОЯЧИТЕ" '> . Бройкането на пакети и т.н. е изключително, ама изключително, повърхностен критерий за оценка.


Преди време един "БРОЯЧ" взе да "умува" колко сложна и голяма била поддръжката на X.509 сертификати в OpenSSL. Интересното бе, че при един от критериите, броеше колко реда има във файловете. Проблема, на такова "бройкане", първо бе, че във всеки файл има лиценз, а "БРОЯЧА"  не изключва тези редове. Като се изключат тези редове, бройката се намалява наполовина. Но основният проблем на такава методика обаче е, че един добре документиран код веднага става лош, защото "бройката"  на редовете, обикновенно, се утроява. И какво става: разработчици никога не си документирайте кода и пишете колкото се може повече код на един ред, защото "БРОЯЧА" не спи '>  и високо ще ви оцени.

Друг "БРОЯЧ" взе, че преброй колко bug-а имало през миналата година в Windows и Linux. И броеше доста интересно. Понеже в някаква справка имало много повече за Linux, значи Windows е по-сигурен. Оказа се, че тази справка е много интересна. Примерно поне при един от критичните проблеми в Windows, имало поне пет(!'> patch-а, в рамките на три, четири месеца, и се засягали десетина продукта. Интересен начин на броене - петдесет bug-а, а ще ги обявяваме като един !

Липсата на зависимости, позволява да се намали значително бройката на пакетите. Нека пакета А, зависи от X,Y,Z и нека потребителя се нуждае от A и X. В пакетна система със зависимости, май трябва да се раздели на няколко A-core, A-X, A-Y, A-Z. Така потребителя като поиска A и X, ще зададе че иска A-X и ще му се инсталират и A-X, и A-core, и X. Ако не се направи такова разделяне, потребителя ще получи и Y, и Z. Ето така пакетната зависимост увеличава и "бройката" на пакетите.

Лично на мен много ми пречат, т.н. devel[opment] пакети.
Към инсталираните A, B, C пакети, ще трябва да се инсталират отделно и обикновенно, допълнително, A-devel, B-devel, C-devel. Някой ще подскаже, ами защото не избереш  A-devel, B-devel, C-devel и от зависимостите ще ти се инсталират и A, и B, и C. Ами просто защото обикновенно A, B, и C са избрани по подразбиране и трябва допълнително да се изберат другите.

И накрая какво стана с A, вместо един - пет пакета.

Ако не ме лъже паметта, в Slackware TeX пакета( tetex?) е само един, а в някой дистрибуции това май са десетки. Не е ли по-лесно да се инсталира само един пакет, вместо да се чуди човек това трябва ли ми, не ми ли трябва? Ще пестим ли от евтиното дисково пространсто, за сметка на трудоемки операции по разпарчетосването.

Цитат (mhydra @ Ян. 25 2006,09:41)

Докато Слак се прави от един човек, то той няма да е конкурентен на другите дистрибуции.

Пакетите да, но ChangeLog.txt показва още колко много хора участват.

[yasnv]

така,горе-долу ме ориентирахте.Изясниха ми се работите(поне частично).Моето мнение е че за мен Дебиан е по-подходящ.

[v_badev]

Цитат (Guest @ Ян. 25 2006,12:25)

Липсата на зависимости, позволява да се намали значително бройката на пакетите. Нека пакета А, зависи от X,Y,Z и нека потребителя се нуждае от A и X. В пакетна система със зависимости, май трябва да се раздели на няколко A-core, A-X, A-Y, A-Z. Така потребителя като поиска A и X, ще зададе че иска A-X и ще му се инсталират и A-X, и A-core, и X. Ако не се направи такова разделяне, потребителя ще получи и Y, и Z. Ето така пакетната зависимост увеличава и "бройката" на пакетите.

Това не е вярно. Ако пакет A зависи от X, Y и Z, то пакетна система със зависимости ще инсталира X, Y и Z при инсталирането на A. Като под зависимост в случая се разбира "пакет без който пакет А няма да работи".

Ако с написаното си имал в предвид че пакет A зависи от X или Y или Z, то тогава пак няма нужда от пакети A-X, A-Y, A-Z. Просто в зависимостите ще пише че е нужен един от трите. Ако не инсталираш специално Y или Z, най-вероятно пакетната система ще инсталира X.

А разделението на A-common и А се налага по съвсем различни причини. Специално в Debian това се прави понеже A-common (или A-core) съдържа файлове които не зависят от архитектурата, например текст, картинки и т.н., а A съдържа програми и библиотеки. Така A-common се пакетира само веднъж, докато A се компилира и пакетира отделно за всяка архитектура.

Уточнение: пакет A зависи от X,Y,X чрез "опционални модули".
Бел.: Примера е измислен само, за да покаже идеята.

Пример: Apache+mod_php+mod_perl+mod_xxx.
При пакетна зависимост е желателно да се разбие на няколко пакета :
- apache_core (core/base/common/  без значение )
- apache_php
- apache_perl
- apache_xxx
Трябва ли да се направи това разбиване - ами не. Като поискаш apache ще получиш и php, и perl, и xxx.
А ако се направи разбиване може да се инсталира само "apache_core", защото останалото не ни трябва .

Когато липсва пакетна зависимост, няма проблем пакета apache да съдържа и mod_php, mod_perl, mod_xxx, като е по подразбиране е конфигуриран без тях. Когато на потребителя се наложи да ползва mod_php, инсталира php и преконфигурира apache. Трябва му mod_perl, mod_xxx - също като за php. Общо взето примера става в 4 пакета. Трудно ми е да си представя при пакетна зависимост да може с по-малко (с един става при всички случай).

Затова смятам че пакетната зависимост води до изкуствено увеличаване на броя на пакетите.

Бел.:В примера по-горе не е толкова важно къде ще бъде mod_php - дали в пакета на apache или в пакета на php.

Край на уточнението.



И сега въпроса колко кучета трябват, за да се пази стадо овце ако те са:
- десет
- сто
- хиляда
- десет хиляди ?
И без да се влиза в спор точно колко трябва да са, е ясно, че с увеличаване на броя на овцете трябва да увеличим и броя на кучетата.

Пакетната зависимост, принуждава правенето на много пакети, от там идва и необходимостта от повече ресурси(хора) за създаването им.

Трудно ми е по бройка на "ГОТОВИ" пакети, да възприема, че може да се каже, че дистрибуцията е по-добра. Какво стана с opensource ?


/извън темата

В един момент намразих SuSE (8.0/8.1 ?) защото не можеше да се компилира OpenOffice. И какво се оказа: ако се приложат само първите 42(?) patch-а към компилатора няма проблем. Bug-ът бил в някой от следващите patch-ове. Май бяха общо над 70(?) . След като не може да се компилира софтуер на една дистрибуция, тя добра ли е ? Ама тя има примерно 2, 3, 5 хиляди готови пакета. Е и ! Ами от останалите възможни 20, 30 хиляди ( дали са толкова малко ), колко няма да може се компилират ?

Ех, че лошо се изказах за SuSE, никак не ми се искаше. Ама OpenOffice беше млад и template-ите на C++ винаги са били проблемни за различните компилатори. Първоначално си мислех разни неща '> за разработчиците и т.н '>  на OpenOffice. Минало, забравено, много добра дистрибуция/офис пакет.