Linux за българи: Форуми

Ако този въпрос го задам на някой сисадмин сигурно ще ме убие с камъни... ...
Ясни ми са предимствата на компилацита от сорс код, но все пак с компилираните пакети се работи много по-лесно : има си база данни с инсталираните, лсно се премахват от системата и т.н. Това че нямам контрол върху опциите на програмата която инсталирам досега ми е създавало малко проблеми.И ако все пак този RPM не ми върши работа - компилирам.
Досега съм работил основно с пакетите идващи с RedHat (моля без отговори от сорта "абе що червената шапка и т.н.")  и не съм имал проблеми.
Е? - какви са ви предпочитанията?
Стана чсно че аз предпочитам RPM.

Със същия успех може да си постнеш и анкетка: Готово ядро от дистрибуцията ли ползвате, или комплилирате свое ???
Ясно за какво става въпрос :)

Айде със здраве

На въпроса не винаги може да се отговори еднозначно - в някои слуаи binary-то е по-подходящо, в други - сорса  
Аз като стар slack фен, винаги когато има възможност си свалям сорса - досега (почти) не съм имал проблеми. Е, трябва да призная че понякога (не много често) ми се е налагало да променя по някой ред в сорсовете или скриптовете, но така (за мен) е по-интересно  
Няма спор че binary инсталацията е много по-удобна и бърза, но за сметка на това src-то почти винаги е по-оптимално.
Все пак понякога ми се е налагало да прибягна до tgz - binary инсталационен формат на slak-а. Преди няколко месеца се опитах да компилирам Mozilla-та - имах 1G свободно на диска и много се изненадах като това не и стигна - изяде цялото свободно пространство   , тогава нямаше как, свалих си binary-то.

Бинарни пакети - за съответната дистрибуция
Компилация от сорс за преход от една на друга или "висш пилотаж" Двете по-скоро се допълват а не са "vs"

nito ednoto nito drugoto. dosega imam 40% uspewaemost pri compilirane . twa za men e shibana rabota. izwinqwam se za izraza, ama si e taka. puskam da se kompilira i to kazwa ami w edna biblioteka deto wika druga biblioteka ima nesaotwetstwie w tipowete !!! a sektir swalqm go os originalniq site za moq linux i pak twa mi mranka!!! binarito w toq si wid sashto ne mi hareswa mnogo. mnogo chesto lipswat biblioteki i izlishno se tormozq da gi tarsq. oshte poweche che ponqkoga iskat i po-stari wersii !!!! za men e naj-dobre RPM+LIB - wsichko nujno na edno mqsto. imam 10 GB free i ne mi puka kolko iska a i neta mi e bezplaten i postoqnnen.

Няма спор, че двете неща се допълват. Проблемът не стои по принцип. Той се появява, когато се запитаме за критичността на приложението, което искаме да инсталираме: дали от него пряко зависи работата на системата, дали е жизненоважно и засяга сигурността и производителността или е без значение. В първия случай, можем да си имаме работа с ядрото, за което стана дума по-горе. Няма начин, добре е да се компилира от сорса и да се оптимизира за конкретната система. Иначе, защо да си губя времето да компилирам licq или някоя друга програмка, от която не зависи нищо, след като си имам готовия rpm пакет?
Нали така, важен е не форматът или начинът на инсталация, важна е целта, с която ще използуваме програмата
А това, че компилацията понякога е просто задължителна, това изобщо не трябва да се оспорва. И все пак, не бива да се подценяват rpm-пакетите. Невинаги можем да изчетем цялата документация, за да изучим опциите, с които да компилираме критични приложения като php или Apache. Без да искаме можем да отворим опасни пролуки в сигурността, които да позволяват на някого да вземе привилегировани права над цялата система. Така че, в такива случаи, или си инсталираме готовия rpm, за който разработчиците на дистрибуцията са се потрудили старателно, или четем мно-о-о-го яко и чак тогава пристъпваме към make, make install.
Хубавото на отворения код е, че ни дава възможността да избираме - усещане, което потребителите на Windows няма как да са изпитали или да могат да си го представят  

Напълно съм съгласен с по-горното мнение. Не трябва да се ползва само едно от двете. В някои ситуации едното е по - добро, а в други - другото.По принцип ползвам пакети за дебиан (с пакетния мениджър на дебиан) и всичко е адски удобно и лесно. Понякога обаче се налага да си компилирам разни неща. Например така и не намерих пакети на mplayer  с gtk поддръжка, а когато се инсталира от нормалните пакети в GNOME-а изглежда много грозно и се наложи да си го компилирам сам с поддръжка на gtk и сега работи страхотно.

Аз като потребител на Gentoo мога да кажа, че portage системата е съчетала до голяма степен предимствата и на двата начина за инсталиране на приложение - компилира се от сорс, има възможност за промяна на опциите при компилиране на даден пакет, решен е проблема със зависимостите, нужните пачове и кръпки идват заедно с приложението и не на последно място опциите по подразбиране са задоволителни поне за Десктоп система.

Предпочитам за:

Desktop -> binary
Server -> binary

Разбира се при нужда от ръчно кърпене -> сорс, ако търся мах производителност и бързодействие пак от сорс, същото важи и за Десктоп машината  

Проблемът е, че има радикална грешка още в дефиницията на темата: "RPM vs. source". А какво да кажем за src.rpm? Има страшно много заблуди и митове по тази тема. Аз предпочитам интелигентната пакетна система, с която си правя бинарни пакети от такива със сорсове. Съхранявам ги в удобно repository и управлявам чрез него N на брой машини у дома и по света Хем оптимизации, хем удобства и пестене на време.

Напълно споделям написаното от Ник

Редактирах заглавието на темата, щото наистина RPM vs. SOURCE беше неточно  

ко ша рече сорс ?
ако е да пишеш маке и маке инстал като гламав ХАХАХА ! .
ако са портс ... бива горе доло
все пак бинарен пакет УПРАВЛЯВА
става по бързо
върви по бързо
поддържа се по лесно
печели се време
времето е пари
печелят се пари.

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

@Joke компилирания сорс винаги ще работи по бързо от бинарния пакет.  

Source  

И аз предпочитам бинарните пакети. Например минаването към KDE 3.5 ми отне ~30 мин. чрез apt-get. Ако бях решил да го компилирам, един ден едва ли щеше да ми стигне.
Да не споменавам ръчното разрешаване на зависимости при компилацията. Често се оказва, че за да компилираш едно приложение, трябва да компилираш още 4-5 преди него... Истински ад.
Но наистина използването само на единия от двата метода е невъзможно, според мен. Понякога ми се налага и да компилирам...

Здравейте,
Аз предпочитам да компилирам от "source" (using "Gentoo" ;-)
След почти пълното единодушие по въпроса че е по-добре ядрото да се компилира ръчно при мен стои дилемата: удобството на бинарните пакети (има такива и в Gentoo) срещу удобството на USE флаговете.
Признавам си предпочитам да компилирам но да мога да настройвам цялата си система (чрез USE-flags).
Отделно удобство е и ползването на допълнителни (според хард. архитектура и личните предпочитания) CFLAGS - които се използват за всички пакети.
PS: цялото KDE-3.5 сигурно ще се компилира за 10-12 часа, но това става докато човек си работи със старата версия ;-). Отделно сега могат да се ползват само отделните програми на KDE а не няколкото голями пакета.
Румен

Тук си личи тоталната непросветеност на много хора. Не се чудудвам обаче от заливащата ни простотия.

1. Митове и легенди за любители на късия разказ са измислиците-премислици за това как като си компилираш пакет на своята си машина и той залепвал за нея и работел супер по-бързо и т.н. Освен за малък борй пакети, които са свързани с периферия, всичко друго е турбо безмислено да бъде компилирано за конкретна машина, защото зависи единствено от архитектурата на процесора. Не ми казвайте само как компилирате пакети за Celleron или за Via C3, че ще почна да се хиля истерично.

2. Дори в рамките на PC архитектурите е доста спорно кои пакети да се компилират за i686 и i386. Общо взето компилацията на пакетите glibc и kernel за i686 има смисъл, доколкото се поддържат архитектурни функции. Опитайте се да намерите записи от лекциите на Алън Кокс и там човекът подробно обяснява защо това е така. Да компилираш обаче glibc на Celleron или на Duron няма никакво значение.

3. Анти системната администрация в стил Gentoo намира своя апогей с компилиране на пакети върху критични работещи системи. Да компилираш пакети на критична система е признат за турбо небрежност и непукизъм към сигурността. Няма да говоря за причиненото натоварване върху системата вследствие на компилация. Ще кажа само, че ако утре излезе "експлоит" в glibc или kernel, докато пакета се компилира може вече системата да я няма. glibc се компилира с часове, същото се касае и за много други пакети. През тези часове можете да палите свещи и да изпълнявате молитвени ритуали с надеждата никой да не се възползва от пробива. Да държиш компилатора на система с много потребители пък е факт, достоен за съжаление. Сетете се защо, ако не се сещате ми дайде шел достъп за да ви подсетя.

Сигурно е хипер модерно да си компилираш пакетите и да се правиш на гъзар или на сорс хипар. Сигурно в средите на лесно впечатляващите се хора това може да е плюс. Но реално погледнато в над 90% от случаите това е едно въртене на цикли и загуба на процесорно време. Вече гледам е въпрос на престиж да използваш дистрибуция, която била само изходен код и сам си компилираш всичко. Иначе те имат за изостанал и непросветен. Направо да паднеш да се хилиш... селяния до несвяст се шири и в линукс средите.

И аз компилирам цяла дистрибуция. Ето ви я:

ftp://fedora.lcpe.uni-sofia.bg/redhat/el4-compiled-by-me/

но за целта си имам "build host" и пакетите се компилират само веднъж върху него и се разпространяват от там в бинарен вид. Далеч съм от жертвоприношения свързани с масови компилирания на пакети където и както ми падне.

BECO, откакто разбивахме с теб отвратителната мутра на Вени Марковски, съм голям фен на литературния ти стил и редовно чета постингите ти на приятелката ми на глас (а тя все пак е редактор на онлайн списание и има понятие от литература за разлика от мен). :) Преди известно време имаше един умопомрачителен (като размери и литературна ценност) флейм на някоя от новините, където съм се смял на глас от звучния и богат език, който използваш.

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

Години наред ползвах slack (с прекомпилираните му пакети за i386/i486). Преди около 2 години изпробвах CRUX и веднага останах на него (до преди половин година). Разликата в бързината беше чувствителна. От тогава гледам да си компилирам софтуера сам и не виждам причина скоро да сменям хардуера си, който е вече стар около 4 години. В момента ползвам FreeBSD и отново съм задал флагове, които да отговарят на процесора ми (athlon-xp).

Чел съм и преди мнението ти за използването на флаговете и все пак ми е чудно, какво мислиш за benchmarks, които се срещат тук таме и все пак показват разлика, която аз само мога да потвърдя с опита си.

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

Бих се радвал ако споделиш, какво мислиш по въпроса и предварително благодаря.

:)

Преди 2 години много дистрибуции бълваха пакети за архитектура "atholon". Примерно вижте архивите с пакети на Red Hat Network. След това хората казаха.. заради до 5% процента повишаване на производителността (и то само в някои случаи), не си струва да компилираме хранилища. И в момента тези пакети ги няма.

Лично аз съм компилирал пакети за фамилията XP на AMD. До момента значително повишаване на производителността съм видял само в случаите, в които компилирам ядрото с поддръжка на OpenMosix. Има специален пач към него за оптимизация към AMD XP архитектура. Но там има пък други особености. Няма да се впускам в подробности, доколкото темата "системи за паралелни  изчисления - гридове" е като море и не мога да пиша роман тук, за да обясня какво всъщност прави това чудо.

Освен това хората не разбират следният много важен факт. Представете си целият куп процесори, разработени примерно за x86 архитектурата. От гледна точка на едно приложение, тези архитектури са еднакви. Такава е целта на производителите им. Като чета приказките по този форум имам чувството, че едва ли всеки производител прави своя архитектура. Разликите в процесорите са в ПРОЦЕСОРНОТО ЯДРО! Да, AMD имат по-оптимизирано процесорно адро от Intel и когато ви се наложи да извършвате математически изчисления свързани с Monte Carlo симулации ще усетите това, защото бързата работа с числа с плаваща запетая е едно от предимствата на AMD ядрото. Но ефектът се дължи на самото процесорно ядро, а не на ядрото на операционната ви система или на специално компилиран към архитектурата пакет.

Здравей,
Преди време също имах duron (после athlon-xp) но компилирах за i686 и нямах особена нужда от -march.-mtune athlon-xp. но не така стоят нещата примерно с i383/i486 (рутери и/или някои embedded системи).
Обратната съвместимост обаче безспорно си има своята цена и тя се увеличава колкото по-назад във времето се отива. Някои дистрибуции вече изискват минимум i686 за да работят (се инсталират).
Темата за OpenMosix е достатъчно специализирана за да бъде давана за пример, по скоро пример би могло да бъде "mplayer,xine" където това безспорно ще има значение.
По третата част - да но ако се компилира с флагове гарантиращи по-голяма обратна съвместимост може да не се използват някои от тези предимства (или поне ще се използват непълно). Защо са иначе флаговете в GCC? ако не за да използва напълно този хардуер?
Румен

Нека и аз си изкажа "компетентното" мнение.

Няма никакъв смисъл да се компилират пакетите от изходен код.

1. Губи се време докато се компилират нещата.
2. И в 99% от случаите системата става по-бавна, отколкото ако инсталирате нещата чрез двоични пакети.

Защо системата става по-бавна?

1. Весо правилно цитира Алан Кокс. Аз ще го повторя. Освен ядрото и някои библиотеки другото няма смисъл да се компилира.
2. Малко са хората, които знаят как да оптимизират ядрото и цялата системата. Ако питате мен, едва ли имат 1000 в целия свят.
3. Като нищо не разбирате вероятността да омажете нещата е доста голяма. Все пак е по-добре да се доверите на хората, които разбират за какво става въпрос.

Тук (http://os.t1.cz/tab.php) има едно "ламерско" сравнение на няколко дистрибуции и BSD-та.

От сравнението се вижда, че Дебиан бие навсякъде Джентуу с изключение на една категория и то разликата е много малка. Докато Апачито на Джентуу е 50% по-бавно от Апачито на Дебиан. Това мисля, че е ясно. Оптимизацията (комплиране на ядрото с/без модули) на Дебиан е правена от професионалисти, които знаят за какво става въпрос. Докато човекът сам си е компилирал нещата при Джентуу и очевидно не е могъл да нацели верните настройки на ядрото. И от там му идва забавянето на системата като цяло.

Учудвам се още, че Убунту е доста по-бавно от Дебиан. Пък аз си мислех, че те само променят Дебиан на Убунту в инсталатора на Дебиан и леко го модифицират в последната стъпка. Ама явно и те се правят на професионалисти и се опитват да правят собствено ядро. Резултатът е видим - дериватът е доста по-бавен от оригинала. Хем по-малко пакети съдържат, хем по-нови и пак са по-бавни.


Извод - сложете ядро и библиотеки компилирани и настроени от професионалисти. Така ще сте сигурни, че нищо няма да омажете. Пък другите пакети си ги компилирайте сами. Така ще получите 0.7% по-бърз пакет. И вероятността да омажете нещо е много малка. Най-много съответната програма да работи 10% по-бавно. ;-)

Здравейте,
Мисля това да ми е последенo мнение по тази тема.
В предните си писания покрай другото се опитах да защитя избора си като обърнах внимания не толкова на бързината (това честно казано почти не ме интересува нито го ценя, особено ако разликата е в рамките на 5-7 дори и 10%).
Това което на мен (лично) ми харесва е пакетната система, USE флаговете и лесната промяна на почти всички параметри, но почти никога само с цел някакво състезание по бързо бягане ;-)
Има си достатъчно добри настройки (по подразбиране) така че те могат и да не се пипат.
При определени ограничения дори могат да се ползват (инсталират) бинарни пакети и не само в началото.
PS: отделно факта че Gentoo от години е в първата десетка на distrowatch.com също би следвало да се вземе предвид. Това обаче нито ме радва безкрайно нито ме разочарова просто потвърждава (за мен) избора ми.
Румен