Re: perl5.8

From

Eugene Grosbein (2:5006/1)

To

Sergey Skvortsov

Date

2006-11-24T01:31:42Z

Area

RU.UNIX.BSD

Reply-To: eugen@grosbein.pp.ru

23 ноя 2006, четверг, в 20:32 KRAST, Sergey Skvortsov написал(а):

 AS>> А где пакадж? :)
 >> Этот вопрос адресуй в re@, мол почему на все комбинации опций
 >> пакеты не строют.
 SS> Вспомни комбинаторику и оцени число комбинаций и вытекающую потребность
 SS> в машинных ресурсах.

Вообще-то это был сарказм, и вопрос о пакете, собранном с
WITHOUT_PERL_MODULES=yes я могу считать лишь шуткой, не слишком уместной
(тем более что смайлик). Именно из-за числа комбинаций
и общей бессмысленности затеи. Пакеты вообще весьма полезные сущности,
но с четко ограниченной областью применимости, шаг влево/шаг вправо
и уже неприменимы, и нужно make звать.

 SS> Твой уровень ожиданий чрезмерно завышен - у себя искать минимальные
 SS> ресурсы для использования системы портов отказываешься (точнее, твоё
 SS> понимание "минимального уровня" явно существенно ниже общего по всей
 SS> массе пользователей FreeBSD),

Вопрос не о конкретно о моем случае, еще раз (там давно все работает).
Вопрос о подходах и границах. FreeBSD 4 еще не умерла (и слава богу),
и для неё граница, видимо, останется на уровне 486 и 8-16Mb для
работы (на 16Mb замечательно работает Hylafax с минимальной нагрузкой)
и порядка 32Mb для возможности пересборок. FreeBSD 5 я на слабых
системах не гонял, ничего сказать не могу. Для FreeBSD 6, видимо,
грань будет порядка P-I и 24-32Mb для работы и около 64Mb для
пересборок, но только если сдерживать оверхед.

 SS> одновременно с чем ожидаешь от open source
 SS> project всего того удобства работы с binary upgrades, которого можно
 SS> ожидать лишь от commercial support (и то, хороший (идеальный) пример
 SS> такого vendor'а непросто привести).

Я вовсе не ожидаю удобства работы с binary packages, наоборот я каждый раз
с удивлением встречаю предложения "пользуйся пакетами", достаточно хорошо
зная, что они могут дать, а чего не могут.

 SS> Уж коль хочется продолжать бесконечный thread, то давайте оценивать TCO
 SS> проекта FreeBSD и некоего образцово-другого. Разумеется, следует выбрать
 SS> исходный scope применения.
 SS> Лично я убеждён, что выигрыш в десятки раз в пользу FreeBSD и уж это
 SS> разница покрывает скромные затраты на build box в несколько раз.

В этом смысле - безусловно. Тут в общем "не битва добра со злом" :-)
Тут сравнение хорошего FreeBSD и его врага - лучшего FreeBSD :-)
Вопрос в том, кто из них кто.

 SS> Те же доводы можно привести, сравнивая developer'а open-source
 SS> приложения, и commercial software company.
 SS> Обвинять же девелопера в завышенной оценке необходимых ресурсов тем паче
 SS> смешно, средний разработчик не использует Xeon-5160+8Gb DDR2-RAM как
 SS> "типичную машинку", и диски в массе у всех примерно одинаковые, и т.д..

Что не использует 8Gb и так далее соглашусь,
а вот что диски и другое у всех в массе примерно одинаковые,
это может и так в некоторой степени (хотя уж слишком расплывчивая
"примерность"), но... У девелопера легко может быть 160Gb диск и ему
выделить 2Gb под /tmp ничего не стоит, но отсюда не следует что
в работе приложение каждого девелопера может рассчитывать,
что 2Gb под временные файлы оно завсегда получит безусловно.
То же с памятью и с CPU. Вот когда "один сервер - один сервис",
оно может и так.

 SS> Частный вариант с embedded systems, надеюсь, вполне очевидно требует
 SS> "внешнего build-box", но и у этого решения есть нижний придел - мечтать
 SS> засунуть что-то на 64Mb отличное от решения специализированной задачи
 SS> конечно можно, но цена затраченных на это усилий уже экономически не
 SS> стоит того - проще немного увеличить сами hardware resources.

Пока мы не начинаем тиражировать решение, даже всего 5-10 экземпляров
и вопрос экономической целесообразности уже опять может быть решен
в другую сторону. Потому что нарисовать сборку образа - один раз,
а железо комплектовать на точки - больше одного.
Кстати, в 64Mb можно уместить очень много. А если компрессию применить,
то и того больше :-)

 SS> Бессмысленно пенять некоего developer'а, что он потерял интерес к некоей
 SS> задаче.

Совершенно бессмысленно; а никто этого и не делает.

 SS> Никто ничего не гарантирует; community - это люди идеями, общими
 SS> по сути, но это и не суровый орден иезуитов, требующих положить жизнь на
 SS> служение сей идее (замечу: "идее" - не endusers).

Угу.

 SS> Лакированный идеализм
 SS> в стиле "The Cathedral and the Bazaar" от Eric Raymond'а прокатывает
 SS> только для людей, для которых такая мотивация почему-то хороша
 SS> (ego-satisfying). Моё субъективное впечатление, что таких людей за эти
 SS> годы стало куда меньше, ментальность меняется в иную сторону -
 SS> осознанного экономического преимущества в sharing'е идей и реализаций -
 SS> причём "вера" апологетов open-source не стала меньше, а число их всё
 SS> растёт.

Именно. Именно преимущество сотрудничества.

Eugene
-- 
И знатную леди от Джуди О'Греди
Не сможет никто отличить.
--- slrn/0.9.8.0 (FreeBSD)
 * Origin: Svyaz Service JSC (2:5006/1@fidonet)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 8 9 10 14 15 16 17 5007/1 5010/70
SEEN-BY: 5011/13 5012/46 5015/28 5019/31 5020/18 175 194 400 545 982 1057 1909
SEEN-BY: 5020/1922 2238 2395 2871 4441 5021/29 5025/3 5026/14 45 5027/12
SEEN-BY: 5030/1080 1957 5034/10 13 5035/3 38 5036/1 5045/7 5049/1 5051/15
SEEN-BY: 5054/1 4 8 9 11 28 35 36 37 45 63 66 67 70 75 84 85 5059/9 5060/88
SEEN-BY: 5061/15 5062/10 5063/3 5064/7 5066/18 5075/5 5076/1 5077/70 5080/1003
SEEN-BY: 5084/9 5085/13 5095/20 5096/18 6001/10

PATH: 5006/1 5020/400 545 5054/1 37