Покотиленко Костик -> [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 ты в этом месте, вероятно, получил бы сегфолт. Ну или (если бы сегфолт вылетел в твоих тестах и ты бы закрылся от него проверкой) невнятное сообщение "мама, тут чего-то не хватает". Перл бы еще рассказал, с какими аргументами была вызвана функция, что позволило бы найти ошибку гораздо быстрее. -- Artem Chuprina RFC2822: <ran{}ran.pp.ru> Jabber: [email protected] Юзер упорствует в хождении по граблям. Образовавшиеся шишки он считает трудовыми мозолями. (С)энта -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
