В Вто, 17/03/2009 в 14:15 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ Mon, 16 Mar 2009 > 19:04:24 +0200: > > >> >> >> >> Демоны почему-то чаще всего пишут не на скриптовых языках. > >> >> >> > > >> >> >> > Ошибаетесь. Большинство написанных в последние несколько лет > демонов как раз > >> >> >> > скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас > же очень много > >> >> >> > написано на скриптовых языках. > >> >> >> > > >> >> >> > >> >> >> > >> >> >> Проверил список демонов на одной из машин > >> >> >> snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, > klog, > >> >> >> mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind > и еще > >> >> >> несколько других - все не скриптовые. > >> >> >> Единственный найденный скриптовый - xen > >> >> > >> >> ПК> spamassassin тоже скриптовый, но это его минус, причём большой. > >> >> > >> >> Минус его не в этом. Сделать ту же обработку на C у тебя, может, и > >> >> получится, но шансы, что она окажется быстрее, близки к нулю. Потому > >> >> что perl заточен ровно под задачи этого класса, и производительность > >> >> _этих_ операций в нем вылизана гораздо лучше, чем это сможешь сделать > ты > >> >> за ограниченное время. > >> > >> ПК> Ты прав, не по тому пути они пошли, но их уже не догнать. > >> > >> Кто "они"? Админы? > > ПК> Разработчики SA. > > А куды им бечь? Не анализировать письмо от слова "совсем"? > > >> ПК> Пойми в чём тут дело? С perl и python всегда так. > >> > >> ПК> downloading servers from > http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x > >> ПК> Traceback (most recent call last): > >> ПК> File "/usr/bin/pyzor", line 8, in ? > >> ПК> pyzor.client.run() > >> ПК> File "/var/lib/python-support/python2.4/pyzor/client.py", line > 1003, > >> ПК> in run > >> ПК> ExecCall().run() > >> ПК> File "/var/lib/python-support/python2.4/pyzor/client.py", line > 184, in > >> ПК> run > >> ПК> self.servers = self.get_servers(servers_fn) > >> ПК> File "/var/lib/python-support/python2.4/pyzor/client.py", line > 409, in > >> ПК> get_servers > >> ПК> servers.read(open(servers_fn)) > >> ПК> File "/var/lib/python-support/python2.4/pyzor/client.py", line > 117, in > >> ПК> read > >> ПК> self.append(pyzor.Address.from_str(line)) > >> ПК> File "/var/lib/python-support/python2.4/pyzor/__init__.py", line > 458, > >> ПК> in from_str > >> ПК> fields[1] = int(fields[1]) > >> ПК> IndexError: list index out of range > >> > >> Вот с python - да, сам регулярно вслух удивляюсь. Вроде бы язык не > >> способствует неаккуратности, а поди ж ты... А с perl - нет. > > ПК> Всё дело в том, что сильно высокие языки много от программиста > ПК> скрывают, упрощают ему жизнь так сказать. Он по этому и не знает, > ПК> что мир реально сложнее устроен. > > Вот тут у меня как раз опыт противоположный. Программист на языке более > высокого уровня гораздо чаще имеет дело как раз с ошибкой "мир устроен > сложнее". В отличие от программиста на более низком уровне, которому от > полученной ошибки до "как в этом месте устроен мир" настолько длинный и > сложный путь, что обработать он ее не может, и потому жухает нах. > > ПК> По этому - чуть шо, получаем какую-то ругань, никому, кроме > ПК> потенциального хакера не полезную. По ней же ничё не скажешь, кроме > ПК> версии python. > > Ну почему "ничё"? Хотя у перла, как мне кажется, обычно с руганью > лучше, но и тут, в общем, можно сказать, что именно слетело. Нету в > fields второго элемента. На C ты в этом месте, вероятно, получил бы > сегфолт. Ну или (если бы сегфолт вылетел в твоих тестах и ты бы > закрылся от него проверкой) невнятное сообщение "мама, тут чего-то не > хватает". > > Перл бы еще рассказал, с какими аргументами была вызвана функция, что > позволило бы найти ошибку гораздо быстрее.
Не спорю. Этот инструмент хорош, но не для фундаментальных задач. -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
