Сообщение от Mark5:
Ant0, поздно - я уже поставил её в начале лета.
pmkras, спасибо, сам чето не нашел ))
Сообщение от :
Дженту... Это надолго
Сообщение от zic:
ну это смотря сколько тебе осталось до того чтобы повзрослеть
Сообщение от :
И тут уместно сказать пару слов еще об одной широко распространенной легенде - будто бы сборка из исходников посредством портообразных управляющих комплексов всегда приводит к более «чистой» (то есть свободной от лишних компонентов) системе. Это далеко не всегда так.
Во–первых, в самой природе портов (и их клонов) часто заложена некоторая избыточность устанавливаемых компонентов. Хрестоматийный пример - cvs-up, требующий для актуализации, как базовой системы, так и портов FreeBSD: в бинарном виде это легкий компактный пакет, не обременяющий даже пользователя с модемным подключением. При сборке же через порты он тянет за собой дистрибутив modula (поскольку на нем написан), который дальнейшем не пригодится никому, кроме приверженцев этого языка программирования.
Что меня всегда удивляло в портах FreeBSD, так это ситуация со сборкой моего любимого редактора joe. Каковой в качестве зависимости непременно требовал GNU make версии 3.80, хотя собственный make входит в состав FreeBSD Distributions и собрать с его посредством joe руками не составляет никаких проблем.
А вообще «чистота» установки пакета очень зависит от конкретной реализации порта. Недавно обнаружил я в новостях сообщение о новом оконном менеджере под названием edo - небольшом, как говорилось, компактном и быстром. Обнаружился он и в портах FreeBSD, откуда я решил его собрать. В итоге этот маленький :-) WM потянул за собой (как зависимость зависимости) не что иное, как MySQL...
Однако если вы думаете, что такое поведение портов - особенность FreeBSD, и создатели их Linux-клонов учли ошибки прошлого, то уверяю это не всегда так. Причем в Linux ситуация усугубляется особенностями базовой системы, точнее, несогласованностью развития отдельных ее компонентов.
Каждый, кому доводилось собирать Linux from Scratch, знает, что некоторые версии пакетов Base Linux имеют обыкновение собираться только с определенными (отнюдь не обязательно самыми свежими) версиями таких утилит, как autoconf и automake, категорически отказываясь делать это с другими их версиями (пусть даже более свежими и прогрессивными).
Разработчики Source Based дистрибутивов Linux подчас обходят эту сложность тем, что принудительно вносят в список зависимостей таких «склизких» пакетов autoconf и automake «прошлогоднего» розлива, притом, что сам по себе базовый комплект включает уже текущие на данный момент их версии. В результате чего, например, в Gentoo при выполнении бутстраппинга или emerge system можно с удивлением наблюдать, как система лезет в Интернет за бородатым, как Карл Маркс, autoconf хотя свежая его версия только что была развернута из тарбалла stage1. А если вспомнить, что многие полагают, будто по настоящему стабильное ядро Linux может быть собрано только с gcc версии 2.9.X, результатом чего оказывается присутствие в системе двух компиляторов, то о какой «чистоте» сборки можно еще говорить?
Впрочем, достижение разумного баланса между развертыванием прекомпилированных пакетов, установкой их из портообразной системы и самостоятельной «штучной» сборкой - тема совершенно отдельного разговора.
Сообщение от :
простота установки, администрирования и поддержки
