Re: perl5.8

From

Eugene Grosbein (2:5006/1)

To

Sergey Skvortsov (2:5054/37.63)

Date

2006-11-16T20:26:08Z

Area

RU.UNIX.BSD

Reply-To: eugen@grosbein.pp.ru

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

 >>> То есть, этот bloat - официальная линия партии?
 >>> Место у меня есть, но gcc ныне на P-166 работает очень неповоротливо.
 SS>> Компилировать что-то на P-166 - это мазохизм в наше время.
 >> То есть, официальная...
 >> Почему-то во время 2.2.x и даже 3.x пересобирать мир на P-166 не было
 >> мазохизмом. Программировать разучились? Кали-юга?
 SS> Потому что железо в наше время необычайно дешево, и не приходится думать
 SS> о том, влезет ли программа на одну перфокарту, а сэкономленное время
 SS> можно тратить на решение более актуальных задач.

Я вообще-то терпеть не могу ярых роповедников "теории устойчивого развития",
но нельзя же и до абсурда доводить. Актуальные задачи будут всегда,
это еще не причина не думать головой.

 SS> Может у меня неверное представление о реальности, но создание
 SS> выделенного build-box'а окупается по времени и ресурсам очень-очень
 SS> быстро.

Созданые build-box окупается только тогда, когда машин много.
Вот для четверки он есть, а для шестерки извиняйте, пока нема.
И кстати "выделенный" build-box наверное тоже окупается,
но только когда машин совсем много, а так у меня все время
это был не выделенный, а один из core роутеров, в котором большую часть
времени многогигагерцовый CPU тупо простаивает :-)

 SS> Точно так же как конфиги хранить в VCS, и т.п. "правильные"
 SS> способы ведения дел.

Конфиги хранить там очень дешево. Выделенный build-box соответствующей
уже другое дело.

 SS>> Есть масса скриптов, которые на Perl/Python/Ruby
 SS>> реализуются ясным и простым образом, и переписывать которые на C - вещь
 SS>> жесточайшая. Посмотри в тот же glib20 и попробуй переписать все скрипты
 SS>> на awk.
 >> Да бог с ним, с awk. Меня интересует, чем думает девелопер,
 >> когда влегкую меняет USE_GNOME=glib12 на glib20 (а проверка показывает,
 >> что и с glib12 все пашет) и почему он не думает про оверхед.
 SS> Рискну предположить, что никому не хочется поддерживать необновляемый
 SS> glib12. Вот и всё.

То есть девелопер вообще не думает в таком случае.
И не думает, в частности, о том что glib12 занимает в 5.5 раза
меньше места на флешке NanoBSD, чем glib2. А чего ему, железо-то дешевое.

 SS>> Что до переписывания на awk/bash... Это админу приятно, когда можно
 SS>> добиться 5% выигрыша по скорости используя awk вместо perl, хотя
 SS>> итоговый результат становится на 30% более unmaintainable.
 >> Скрипты awk замечательно маинейнятся. Или ты хочешь сказать,
 >> что знающих awk осталось настолько мало, что в случае чего некому
 >> будет править авковые скрипты?
 SS> Думаю да. Разработчик может знать perl - но нафига ему знать awk?
 SS> Никто же не редактирует файлы в ed.

Что не мешает использовать sed. Нафига ж тогда было потрачено
столько усилий на историю с one true awk?

 SS> Скажем я знаю с десяток языков, и именно это даёт мне полное основание
 SS> использовать только скажем 3, поскольку ну не надо больше.
 SS>> Разработчику
 SS>> же - удобнее знать С для написания основного кода и Perl для
 SS>> вспомогательных скриптов. Всё. К чему лишний аскетизм? Зачем
 SS>> ограничивать себя pidgin english, когда можно говорить полноценно?
 >> Потому что надо оценивать оверхед.
 SS> "оверхед" на что? На время сборки?

В том числе.

 SS> Вот уж что несущественно, в случае скриптов.

И так 10000 раз?

 SS>> А "тратить ресурсы на установку из портов" - это даже не смешно.
 SS>> "pkg_add -r perl5.8" - и всё.
 >> А типа трафик бесплатный и время на эту операцию тоже.
 SS> Уф... Зато софт бесплатный. Зато размер package как правило сильно
 SS> меньше размера distfile, который тоже качается, и устаревает столь же
 SS> быстро.

Дистфайл качается в /usr/ports/distfiles, который один на всю сеть,
и из одного дистфайла делается куча разных сборок.

 >> Кстати, pkg_add -r работает вот прямо так далеко не всегда - 
 >> не всегда он находит правильные дистфайлы, разве что в релизах с этим
 >> проще.
 SS> pkg_add ищет packages а не дистфайлы.
 SS> И смотрит он их в packages/Latest. Так что как он может "не всегда"
 SS> найти - мне неясно.

Сейчас не помню деталей, когда в следующий раз напорюсь - сообщу.
По-моему, я как раз OpenOffice пытался поставить при помощи pkg_add
и в результате пришлось лазить вручную по зеркалами, выкачивать
файлы чтобы потом запускать pkg_add в локальном каталоге. Или это было
с KDE. И по-моему, через неделю после выхода релиза OO или KDE.
Короче, не всегда находит. То, что в Makefile порта. А кроме как
в Makefile, опять же негде посмотреть, чего аргументом pkg_add давать.

 >>> Например для quagga perl требуется только при сборке.
 >>> Нет шестерки под build-box, иначе бы конечно не собирал тут.
 SS>> Ты хочешь заменить недостаток своих ресурсов лишним геморроем для
 SS>> разработчиков.
 >> Я такой не один, если бы речь шла только обо мне...
 SS> Для таких случаев есть лишь один выход - packages.
 SS> То, что default config для порта может не нравиться - да, это сложный
 SS> вопрос. Ничего умнее создания slave-порта пока не придумали.

Вот-вот, и так каждый раз у меня почему-то. Как дело доходит
до практики, пакетами ставиться только что-то совсем простое
или безальтернативное.

А еще есть локальные патчи, мне например абсолютно не нравится поведение
ripd в смысле ругани на пакеты от неизвестных хосту IP-сетей,
а точнее RIP-роутеров из этих сетей, находящихся в одном сегменте
бродкастов с ripd. IMO, абсолютно незачем так орать в логи, 
порождая многомегабайтные совершенно необозримые простыни,
что фактически эквивалентно полному убиению лога, ибо заметить
в нем что-то полезное не представляется возможным.
Я всегда эту ругань в #if 0 заворачиваю, а значит пакет уже идет лесом.
И таких случаев может быть много.

 SS> Можно было бы придумать набор preset configurations для создания
 SS> packages ... но лично мне лениво додумывать эту идею, поскольку свой
 SS> build-box сделать проще.
 SS>> Тратить его на ненужную
 SS>> оптимизацию (минимизацию) - пустое занятие.
 >> Ты сам себе противоречишь. Оптимизация - это экономия времени,
 >> времени тех, для кого все это пишется. Какой смысл экономить время
 >> разработчика, если результат из-за code bloat хренов?
 SS> Ненужная оптимизация - это тратить 2 часа на рисования скрипта на
 SS> sh/awk, вместо 20 минут на написания его на perl/ruby, если данный
 SS> скрипт нужен лишь при сборке софта.

Ага, пусть потом тысяча пользователей потратят по 2 часа лишних,
собирая ненужные glib2 и perl. Зашибись оптимизация :-)
Если мне будет нужна коммодизированная OS, куплю себе MAC и OSX :-)

 SS> Давай не путать build-dependencies и runtime-dependencies.
 SS> Первые, честно говоря, могут быть сколь угодно большие
 SS> (autoconf/automake/bison/perl/flex/ruby ...) - на build-box'е
 SS> бессмысленно жалеть дисковое место.

Нельзя заставлять каждого иметь build-box.

Eugene
-- 
Three things are certain:
Death, taxes and lost data.
Guess which has occurred.
--- 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