ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Eugene Grosbein                      2:5006/1       24 Nov 2006  02:31:42
 To : Sergey Skvortsov
 Subject : Re: perl5.8
 -------------------------------------------------------------------------------- 
 

 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> Hикто ничего не гарантирует; 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
 -- 
 И знатную леди от Джуди О'Греди
 Hе сможет никто отличить.
 --- slrn/0.9.8.0 (FreeBSD)
  * Origin: Svyaz Service JSC (2:5006/1@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор