Изпечатай

• RPM или друг binary формат

  34 (60.7%)

  SOURCE code

  22 (39.3%)

Общ брой гласове: 61

[ray]

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

[vesselinkolev]

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

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" и пакетите се компилират само веднъж върху него и се разпространяват от там в бинарен вид. Далеч съм от жертвоприношения свързани с масови компилирания на пакети където и както ми падне.

[betso]

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

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

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

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

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

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

:)

[ray]

Цитат (vesselinkolev @ Ян. 31 2006,01:28)

Тук си личи тоталната непросветеност на много хора. Не се чудудвам обаче от заливащата ни простотия. 1. Митове и легенди за любители на късия разказ са измислиците-премислици за това как като си компилираш пакет на своята си машина и той залепвал за нея и работел супер по-бързо и т.н. Освен за малък борй пакети, които са свързани с периферия, всичко друго е турбо безмислено да бъде компилирано за конкретна машина, защото зависи единствено от архитектурата на процесора. Не ми казвайте само как компилирате пакети за Celleron или за Via C3, че ще почна да се хиля истерично. 2. Дори в рамките на PC архитектурите е доста спорно кои пакети да се компилират за i686 и i386. Общо взето компилацията на пакетите glibc и kernel за i686 има смисъл, доколкото се поддържат архитектурни функции. Опитайте се да намерите записи от лекциите на Алън Кокс и там човекът подробно обяснява защо това е така. Да компилираш обаче glibc на Celleron или на Duron няма никакво значение. 3. Анти системната администрация в стил Gentoo намира своя апогей с компилиране на пакети върху критични работещи системи. Да компилираш пакети на критична система е признат за турбо небрежност и непукизъм към сигурността. Няма да говоря за причиненото натоварване върху системата вследствие на компилация. Ще кажа само, че ако утре излезе "експлоит" в glibc или kernel, докато пакета се компилира може вече системата да я няма. glibc се компилира с часове, същото се касае и за много други пакети. През тези часове можете да палите свещи и да изпълнявате молитвени ритуали с надеждата никой да не се възползва от пробива. Да държиш компилатора на система с много потребители пък е факт, достоен за съжаление. Сетете се защо, ако не се сещате ми дайде шел достъп за да ви подсетя. Сигурно е хипер модерно да си компилираш пакетите и да се правиш на гъзар или на сорс хипар. Сигурно в средите на лесно впечатляващите се хора това може да е плюс. Но реално погледнато в над 90% от случаите това е едно въртене на цикли и загуба на процесорно време. Вече гледам е въпрос на престиж да използваш дистрибуция, която била само изходен код и сам си компилираш всичко. Иначе те имат за изостанал и непросветен. Направо да паднеш да се хилиш... селяния до несвяст се шири и в линукс средите. И аз компилирам цяла дистрибуция. Ето ви я: <a href="" target="_blank">ftp://fedora.lcpe.uni-sofia.bg/redhat/el4-compiled-by-me/</a> но за целта си имам "build host" и пакетите се компилират само веднъж върху него и се разпространяват от там в бинарен вид. Далеч съм от жертвоприношения свързани с масови компилирания на пакети където и както ми падне.

Здравейте,
Не съм съгласен с @vesselinkolev, сега по ред:
1.Защо ли тогава в GCC има въобще някакви опции за различните архитектури? Я да ги махнат!
2.Тук сигурно искаш да кажеш, че разликата между i386 vs i686 сигурно е само в честотата на процесора, няма такива неща като "mmx,3dnow,sse". Въобще защо ли ги слагат тези хора, да усложняват живота на другите.
3.Не знам защо но си спомних за няколко критични дупки, за които имаше само пач (в рамките на няколко часа, ден) и трябваше ръчно да се приложи и *компилира* за да се *стегне* системата, иначе ще си чакаш д а излезе поправен пакет от разработчиците.
За натоварването на системата си има частичен изход - niceness.
Не мога да не си спомня че преди време имаше една машина с shell достъп, и дори целта бе някой да я свали (седя поне около седмица).
Вярно не беше с source-базирана дистрибуция (не че няма и такава ;-)
4.Може пък да искам *да хабя цикли* е цел да направя така че даден пакет да поддържа примерно само postgresql (без mysql) може и обратното. Или да имам поддръжка (гр.интерфейс) за Qt но не за GTK, или пък само за ncurses/slang. Някои от тези неща се решават (от бинарните дистрибуции) но за другите някой разработчик прави преценка и всички го ползват така.
Няма да споменавам въпроса за нуждата (често) от преинсталация при излизане на нова версия (нови glibc, GCC и т.н. проблеми).
Леко отклонение: защо пък ще искам да се доверявам на *теб* (с твоя CHOST, CFLAGS и т.н.) като мога да си сложа мои?
Естествено има трудности при поддръжката на много компютри с Gentoo (например), но и за това има частични (не лоши) решения, отгатни какви.
Хайде стига толкова.Румен

[vesselinkolev]

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

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

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

[ray]

Здравей,
Преди време също имах 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% по-бавно. ;-)

[n_antonov]

Цитат (ray @ Ян. 31 2006,11:55)

Не мога да не си спомня че преди време имаше една машина с shell достъп, и дори целта бе някой да я свали (седя поне около седмица). Вярно не беше с source-базирана дистрибуция (не че няма и такава ;-)

Дистрибуцията беше Debian с RSBAC пачове на ядрото. Стоя достъпна две седмици. Спрях експеримента, защото машината ми трябваше. Човекът, който я събори, след като изключихме някои рестрикции, за да може да проведе експериментите си, се казва Георги Гунински и мисля няма какво да си говорим дали е случаен.

Относно оптимизациите и компилирането от изходен код за критични системи. Правя го само при необходимост. Например трябва ми да вдигна лимита от 256 едновременни клиента на apache (наистина е нисък за натоварени сайтове), но си пресмятам мощността на хардуера и колко би могъл да поеме. Компилирането на ядро и libc е добра идея за Xeon базиран сървър, с каквито основно работя от известно време насам, но дори и това избягвам да правя, след като в Debian са предвидили също 64-битови версии на libc и на основни библиотеки, от които наистина зависи производителността.

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

[ray]

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

[Dimitar_Ouzounoff]

http://www.linux-bg.org/cgi-bin....t=12514