Представители организации Internet Systems Consortium (http://www.isc.org/) (ISC) объявили (http://www.linuxpromagazine.com/Online/News/CeBIT-2010-Previ...) на выставке CeBIT 2010 о прогрессе в разработке принципиально новой реализации DNS-сервера Bind. Проект BIND 10 (https://bind10.isc.org/), в рамках которого в апреле прошлого года началась работа по созданию переписанного с нуля DNS-сервера, приближается к стадии выпуска первого экспериментального релиза, который намечен на 19 марта. Код BIND 10 в своей основной массе написан на языке Python с реализацией требующих высокой производительности частей на языке C++. Исходные тексты распространяются в рамках лицензии BSD.
Ветка BIND 10 развивается при поддержке крупнейших мировых регистраторов доменов и отличается главным образом улучшением масштабируемости (средствами для организации кластеров) и полностью модульной структурой: резолвер, подсистема для хранения данных (классическая файловое хранилище или SQL-ба...URL: http://www.linuxpromagazine.com/Online/News/CeBIT-2010-Previ...
Новость: http://www.opennet.me/opennews/art.shtml?num=25673
>Код BIND 10 в своей основной массе написан на языке PythonМне одному стало страшно?
Страшно за то, что будет меньше ошибок типа переполнения буфера, как в C/C++?
Как ни странно, криворукий програмер всегда найдет где лажануться. Вон на вебприложения посмотреть. Да, там нет переполнений буфера, зато других типов уязвимостей - как грязи! А что, SQL-injection в DNS сервере - сильно :).Прямо таки новые горизонты, вашу мать.
dns-сервер будет, безусловно, рад sql-запросу
А админ будет рад? Я бы не хотел чтобы мне дропнули таблицы например одним чихом. В этом плане от SQL одна головная боль. А памятуя о дырах в bind - как-то не по себе. А питон не предвещает ничего хорошего, ибо сигналит о том что пишется сие в пожарном порядке.
я ещё раз спрашиваю. как бинд, сервис разрешения имён, связан с sql?
Да.
Нет. Как минимум есть еще я.
/me считает что за bloat в системных сервисах надо попросту расстреливать без суда и следствия.
>Нет. Как минимум есть еще я.
>/me считает что за bloat в системных сервисах надо попросту расстреливать без
>суда и следствия.Перепиши на ассемблере, поможешь проекту.
1. На ассемблере непортабельно.
2. К счастью есть другие проекты.
3. Даже если вы расшибетесь в лепешку, если некто решил стать монстром энтерпрайза и заложил соответствующие принциы на фазе проектирования и ранней разработки - можете хоть двоичный код вместо ассемблера сгенерить лично, опухнув при расчете тактов проца. Это вам не поможет. Дурные решения на фазе проектирования могут спустить в туалет даже абсолютно геройские потуги кодеров. И вот тут мне не нравятся принятые решения. Чуваки явно хотят быть энтерпрайз-поделкой обвешанной фенечками, при том - писаной по принципу как будто оно всем было нужно еще вчера. Ну, наверное, ISC сильно хочется начать стричь купоны как можно быстрее, оттуда и спешка. Со всеми вытекающими. И никакие отдельные кодерские потуги это не пролечат нифига. В общем имхо драпать мне придется с этого монстрила - я не собираюсь закупаться кластерами спецом под это. Пусть админы корневых серверов покупают супер-дупер кластера и расширяют их до позеленения, если у них баблосов много.
Хм, похоже, что лично я останусь на 9-ке.
Похоже что лично я призадумаюсь что это монстрило пора выбросить. Оно и в 9-й то версии ресурсов жрет порядочно, представляю себе что будет когда они это перепишут на питоне и понаворотят фич. Интересно, им производители серверов приплачивают? :)
Если оптимизировать всё, что может тормозить на питоне, то на C++ должно быть 99% кода, а питону остаться пара конфигурялок
>Код BIND 10 в своей основной массе написан на языке PythonЯ перечитал дважды. Программистам bind'a, конечно, виднее, но чувство, что что-то не так, меня всеравно не покидает.
Конечно, ведь питон юзают только затем чтобы за короткий срок наворотить максимум барахла по принципу "на отвали". А питон в системном сервисе - вообще звиздец.
Система портеджей - системный сервис? Я думаю, гентушники с тобой бы поспорили.
Я бывший гентушник. Я не в восторге от перехода с python2.4 на python2.5 и поломки emerge. Я также не в восторге от скорости portage в целом. Точно можно быть уверенным, что десятому бинду закрыт путь на домашние роутеры и т.п.
>путь на домашние роутеры и т.п.Простите, девятый то на них вкорячить проблематично. Да что там, его проблематично даже на недорогих VDSных тарифах содержать, ибо жрет половину ресурсов под себя а платить за только днс сервер - дураков немного. Ну, понятное дело, энтерпрайзам то не привыкать кластеры городить на каждый пшик и расширять их до упора под питоновые конструкции, в конце концов под яву и пых расширяют же, ну и под днс какнить расширятся :).Но мне такой днс нафиг не нужен. Вообще. Хотя-бы потому что в большинстве мест где я имею дело с днс отдельная машина под NS сервер редкое явление а оплачивать кластеры из своего кармана под днсники я как-то не готов.
>Система портеджей - системный сервис? Я думаю, гентушники с тобой бы поспорили.Я не думаю что люди которые вечно все перекомпиливают сильно ценят свое время или какое-то там потребление ресурсов. Их пардон компилить полоси по полдня - не напрягает совершенно. А мне нравится dpkg/aptitude. Без всяких там питонов. Я могу понять зачем скриптоязык в автоматизации, он там удобен. Но вот нахрен надо системные тулзы или тем более демоны на скриптоязыке - я не вдупляю. Это какое-то извращение. Еще б кернел на питоне написали, чего уж мелочиться то?
http://juliank.wordpress.com/2009/08/24/the-apt2-project/
aptitude же на perl'e...
>aptitude же на perl'e...$ file `which aptitude`
/usr/bin/aptitude: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
$ ldd `which aptitude`
linux-gate.so.1 => (0xf7ef6000)
libapt-pkg-libc6.7-6.so.4.6 => /usr/lib/libapt-pkg-libc6.7-6.so.4.6 (0xf7e2c000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xf7dee000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xf7de7000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0xf7d23000)
libept.so.0 => /usr/lib/libept.so.0 (0xf7c62000)
libxapian.so.15 => /usr/lib/libxapian.so.15 (0xf7b0c000)
libz.so.1 => /usr/lib/libz.so.1 (0xf7af7000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xf7ade000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf79ef000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xf79c9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf79bc000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xf7861000)
libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xf785d000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xf7858000)
/lib/ld-linux.so.2 (0xf7ef7000)
$ _Я что-то пропустил?
Нет, это я под вечер тупанул. Просто запомнилось, как при установки aptitude в минимальной системе ставится несколько perl модулей или как-то так.
>aptitude же на perl'e...А я то думал - на плюсах. Как максимум - у убунты апгрейд-скрипты релизов на питоне. Ну сие работает единоразово и в заранее известные моменты, посему скорость и потребление ресурсов не так уж важно и там оно еще выглядит оправданным и логичным - как раз из разряда системной автоматизации задачка. А вот постоянно висящая тормозилка на скриптах или часто пинаемая - нафиг-нафиг. Зачем мне тормозить мои системы всяким барахлом? Безусловно - приколисты даже вебсервак на bash сделали. Но вот юзать его для отгрузки чего-то кроме 1-2 файлов раз в сто лет будет только псих. Не вижу чем питон в этом плане лучше - весьма тормозная штука требующая раскочегарки огроменного интерпретера (в разы более пухлого чем bash даже).
>Конечно, ведь питон юзают только затем чтобы за короткий срок наворотить максимум
>барахла по принципу "на отвали". А питон в системном сервисе -
>вообще звиздец.Вообще, согласен. Но с другой стороны посмотри, в Ubuntu его продвигают как часть стека. Ты смотрел схему десятого бинда? Может, они питон используют только для парсинга конфигов, супервизора и UI. Может девелоперы хотят обогнать релиз samba4?:) Короче, может, это все неизбежное "зло" XXI века, как Java, web2.0 и проч.
>Java, web2.0 и проч.Хм... Java используется раз в сто лет. А веб 2.0 не так уж и плох, если реализован с умом. Куда лучше если отрисуется лишь измененная часть страницы вместо релоада гигантской портянки. Ждать меньше, тормоза незаметнее и не так мерзко выглядит для юзера. Понятно что можно перегнуть палку. Но посмотрев на каконйить вэбфейс трансмиссии (кстати там как сервер вообще чисто сишный демон) понимаешь что иногда AJAX и т.п. бывает полезен. Без него некоторые вещи были бы мучительны и тормозны, отдавая диалапщиной девяностых. А что до релиза так имхо днс сервак - штука которая делается на века (а вы будете часто переколбашивать ваш днс сервак? Я вот днс ни за что не буду лишний раз трогать если все работает, пардон!). Не вижу куда торопиться при его написании (разве что бабло рубить сильно охота как можно быстрее?).
>Конечно, ведь питон юзают только затем чтобы за короткий срок наворотить максимум
> барахла по принципу "на отвали"А, допустим, про Mercurial вы когда-нибудь слышали?
Слышал. И? Я им не пользуюсь и как-то все интересные мне проекты как-то тоже. So what?
А то, что это отличная распределенная система SCM, и написана она на Python. Mercurial никак не подпадает под понятия "на короткий срок" и "барахло", о которых вы говорили.
>"барахло", о которых вы говорили.Но оно и не системный сервис как DNS, пардон. А тул для програмерской машины. На програмерской машине может и какойнить netbeans монструозный стоять. Это не значит что я пропрусь от идеи вкатить столько гуано на мои сервера и потом бодаться с его администрежкой там. Сдалось мне греть мозг когда в питоне в очередной раз сломают совместимость и содержать террариум разных версий, ага.
>Конечно, ведь питон юзают только затем чтобы за короткий срок наворотить максимум
>барахла по принципу "на отвали". А питон в системном сервисе -
>вообще звиздец.Ну да. А ребята из гугла то не знают!
>Ну да. А ребята из гугла то не знают!А гугле хренли, они богатые :). Они и серваков в кластер для какого-то там name server'а не развалятся докупить абсолютно. Что им там плюс-минус пяток серверов когда их там у них тыщщи :)
>какого-то там name server'а не развалятся докупить абсолютно. Что им там
>плюс-минус пяток серверов когда их там у них тыщщи :)Что вы панику разводите, основной цикл обработки запросов как был на Си так и останется, на python переписывают некритические сервисные обвязки, что IMHO абсолютно верный подход - с одной стороны возрастет масштабируемость и удобство использования, с другой скорость даже может возрастет, так как код, вызываемый для непосредственного обслуживания запросов будет по максимуму оптимизирован.
По общему дизайну всего этого видно что чуваки решили сделать что-то энтерпрайзненькое. Со всеми вытекающими. Лично мне по общему дизайну и вектору развития этой штуки очевидно что мне надо подыскивать себе что-то иное. Это я использовать не буду. Сами бодайтесь с совместимостями питонов по версиям, дырами и багами (которые неизбежно будут оптом когда как обычно рапидно налабают на питоне кучу фич а отладить все это ессно как обычно не осилят, больно уж знакомая картина - в сад).
http://bind10.isc.org/browser/trunk/src/lib/exceptions/cpp/e... мне уже страшно
они делают try на c_str
это будет жалкое подобие убожества написаного на С++, и после этого у многих сложиться мнение что С++ плохой язык
пусть уж лучше бы они этот бинд на питоне писали и С++ не марали
Они еще и издеваются:> подходящие для использования во встраиваемых устройствах с ограниченными ресурсами;
А они встраиваемые устройства то видели вообще, или так, для красного словца ввернули? Там питон как правило отсутствует, а его скорость работы.... oO. И жрач несколько метров оперативы чисто под питона - гхм, пусть убьются веником и посмотрят сколько там кушает dnsmasq какойнить.
>> Код BIND 10 в своей основной массе написан на языке Python
> Мне одному стало страшно?У меня ещё возник вопрос а как там с совместимостью с Python 3? BIND - вещь фундаментальная. Не хотелось бы из-за него тащить 2-ю ветку ещё неопределённое колличество лет.
Мне тоже страшно. Мир явно катится не туда.
незнание часто порождает страх, не волнуйся, все будет хорошо
> подходящие для использования во встраиваемых устройствах с ограниченными ресурсами;а питон? :-/
Подумаешь, пяток мегов памяти сожрет. Правда вот если их всего 8-16 - это будет номер :)
А пожелания Google там тоже учтены?
Питон! е-мое и мне страшно стало =(
теперь его точно выкинут из FreeBSD.
>теперь его точно выкинут из FreeBSD.наоборот, с лицензией BSD, его добавят в BSD, а вместе с биндом и питон в BSD добавят - вот за это надо бояться
А это что?
это порт. а поскольку bind системный сервис идущий внутри комплекта freebsd то и язык придётся включать в этот комплект.
не смешите мои тапочки! такого ТОЧНО не будет. Фряшники не будут добавлять в дистрибьюшн никакой язык! Это уже пройденный этап (вспомните перл)
вы это так написали, как будто знаете почему perl из системы вынесли
Переписанный с нуля всего за один год. ВОт она скорость разработки без велосипедостроения. Си и Сиплюсы нервно курят в стороне.
Скорость разработки нужна при ловле блох. При написании индусского кода, который никто никогда не увидит и который кроме вас никому не нужен. При сдаче курсовых она нужна.Я не особо в курсе, как в питоне со строгой типификацией, но заместо известных опасностей переполнения, утечек памяти и прочей стрельбы в ногу с пойнтерами в сях, из питона имеем опасность того, что переменная, имеющая задачей своей хранить 0 или 1, вдруг окажется равной "я-цифро-ноль!", или чего хуже, "eval("rm -rf /")". Элементарно же.
Короче, если на столь критическое дело в ISC не нашлось дюжих программистов на сях, способных не повестись на маркетинговый ход о необходимости сборщика мусора и т.п., чем публику в сях пугают, то мне грустно.
>Я не особо в курсе, как в питоне со строгой типификациейНасколько мне известно, в питоне динамическая типизация.
>но заместо известных опасностей переполнения, утечек памяти и прочей стрельбы в ногу с пойнтерами в сяхУ каждого языка свои особенности/достоинства/недостатки. Пока трудно сказать, является ли применение питона вместо си/си++ оправданным, время покажет и расставит все на свои места.
А вы когда-нибудь смотрели код от ISC? Я знаю - нет, не смотрели! Потому что если бы смотрели, то не говорили бы такой ерунды. Я тоже кстати так как вы думал, пока не покопался в коде ISC DHCP...
Упс, не туда ответил. Ответ был про "профессионалов в ISC" - пост ниже.
>А вы когда-нибудь смотрели код от ISC? Я знаю - нет, не
>смотрели! Потому что если бы смотрели, то не говорили бы такой
>ерунды. Я тоже кстати так как вы думал, пока не покопался
>в коде ISC DHCP...Ну и как код-то был? Сейчас вот кстати пишут, что разработка десятого бинда будет больше вестись независимыми разработчиками...
>[оверквотинг удален]
>Я не особо в курсе, как в питоне со строгой типификацией, но
>заместо известных опасностей переполнения, утечек памяти и прочей стрельбы в ногу
>с пойнтерами в сях, из питона имеем опасность того, что переменная,
>имеющая задачей своей хранить 0 или 1, вдруг окажется равной "я-цифро-ноль!",
>или чего хуже, "eval("rm -rf /")". Элементарно же.
>
>Короче, если на столь критическое дело в ISC не нашлось дюжих программистов
>на сях, способных не повестись на маркетинговый ход о необходимости сборщика
>мусора и т.п., чем публику в сях пугают, то мне грустно.
>Тип легко проверяется, и вряд ли в ISC непрофессионалы сидят.
Как видно по описанию, десятый бинд это большой шаг вперед. На сях видимо его написать было совсем нецелесообразно в плане дальнейшего развития и поддержки
>вряд ли в ISC непрофессионалы сидят.Ну, если посмотреть на число дыр в оном и пожирон ресурсов 9-й версией, данная фраза уже не вызывает такой железобетонной уверенности.
>Скорость разработки нужна при ловле блох. При написании индусского кода, который никто никогда не увидит и который кроме вас никому не нуженВидно, что не в теме, в об индустрии программирования знаешь понаслышке. Второй курс, или таки первый? :)
Вы хотите сказать, куда нам до вашего третьего, да еще и умных книжек начитавшегося про "индустрию"?
Я хочу сказать, что я, хоть и работаю в индустрии всего четвертый год, хорошо представляю, что программисты получают зарплату (а хорошие программисты - хорошую зарплату) не за сферическое быстродействие супер-кода на супер-языке, а за доведение продукта до состояния готовности за разумные сроки. И речь как раз не о спешке, а о _разумных_сроках_.По этому показателю в ряде задач пайтон не имеет равных.
З.Ы. Книжки читать не вредно, не надо говорить, будто это что-то плохое ;)
>По этому показателю в ряде задач пайтон не имеет равных.Да, сразу заметно что вы 4 года штаны протирали в роли какого-то не сильно одаренного мозгом кодера, видимо. Ключевое слово в вашей фразе - в ряде задач. И у меня есть *большие* сомнения что DNS сервак это именно та задача где кому-то сдались плюсы питона. Ну разве что ISC может быть хочет сделать энтерпрайз поделку и подороже впарить ее энтерпрайзникам из Fortune TOP 500 - тогда может быть. И то не понимаю накукуй там питон. Даже у мс относительно легкий сервис живет отдельно от нифига не легкого гуя. Кто-то решил перелюнуть их по степни дерьмовости продукции? Удачи в этом начинании. А как QA с многолетним стажем могу посоветовать ISC убиться веником с таким подходом. Хорошо еще что с ними все понятно уже на этой, ранней стадии. Буду заранее присматривать себе что-то менее энтерпрайзное :)
>Переписанный с нуля всего за один год. ВОт она скорость разработкиА, простите, куда спешка при разработке DNS сервера на годы и годы? Это ж не приложение для бизнесхренов которое нужно еще вчера. А системный сервис. Впрочем вот это - скорее называется "монструозный переросток".
ISC Bind сильно стали теснить другие DNS-серверы. Ну хотят хостеры в sql хранить конфигурацию, хотят embedded-щики легковесное что-то. Ни то, ни другое никак не ассоциируется с Bind
Я таки ДОЖИЛ до этого !!! :) Не вижу повода не выпить!Лишь бы не сотворили очередного монстра который умеет всё - но плохо :)
>Лишь бы не сотворили очередного монстра который умеет всё - но плохо :)Судя по описанию намечается именно это.
1) Питон. Я вижу только 1 причину зачем он может быть нужен. Это как раз сделать "очередного монстра который умеет всё - но плохо". Собственно это единственное что на питоне получается как правило :)
2) SQL и просто файлы - в ту же степь.Итого - получится архимегамонструозный комбайн. Который умеет все, но плохо. А как питон с немножко плюсов может быть хорош в embedded про который они заикнулись, например? Да там один интерпретер питона только съест больше чем все остальное вместе взятое, блин oO
>[оверквотинг удален]
>1) Питон. Я вижу только 1 причину зачем он может быть нужен.
>Это как раз сделать "очередного монстра который умеет всё - но
>плохо". Собственно это единственное что на питоне получается как правило :)
>
>2) SQL и просто файлы - в ту же степь.
>
>Итого - получится архимегамонструозный комбайн. Который умеет все, но плохо. А как
>питон с немножко плюсов может быть хорош в embedded про который
>они заикнулись, например? Да там один интерпретер питона только съест больше
>чем все остальное вместе взятое, блин oOМожет быть тут с заделом на будущее. эмбеддед системы на месте тоже не стоят
>Может быть тут с заделом на будущее. эмбеддед системы на месте тоже не стоятДействительно, можно и Cray заэмбеддить в принципе. Наверное, ISC именно это имели в виду.
https://bind10.isc.org/wiki/DesignDiagrams до кучи
Лушче уж тогда пусть NSD и Unbound допилять хорошенько. NSD для встраиваемых очень даже.
В встраиваемых обычно довольствуются DNSMASQ, хоть он и не совсем DNS сервер. В свете этого писк про питоноподелку в embedded выглядит эпично. Да один только интерпретер питона жрет в 100500 раз больше ресурсов чем весь этот мелкий демон. И да, вот что-что а dnsmasq интегрирован с DHCP. Интегрированнее некуда - этот мелкий демон заодно еще и DHCP серваком является.
Ты по-мойму не понял о каких встраеваемых я говорю, про длинки тут пожалуйста не надо.NSD кушает мало памяти, rfc1035 compliant.
Ололо! Долой питононенавистников! Посмотрим, каков python в деле! Скорей бы уже оно вышло...
>Ололо! Долой питононенавистников! Посмотрим, каков python в деле! Скорей бы уже оно
>вышло...А Google разве не показал каков Python в деле? =)
>А Google разве не показал каков Python в деле? =)Canonical показал, блин! :E Их ланчпад очень часто в дауне и икает таймаутами. Как вы думаете, что там тормозит? Ну наверное не отгрузка статики, а? :)
Перепиши ланчпад на сях ;)
>Перепиши ланчпад на сях ;)Ну вон фэйсбук сделал конвертор пыха в плюсы в итоге :).А питонисты уже показали всему миру с ланчпадом что питон - тормоз, который загибается как только нагрузка становится мало-мальски серьезной. Вот честно, ну зае... же там таймауты. Почему-то у остальных сервисов невзирая на легионы юзеров нет такой жопы.
>>Перепиши ланчпад на сях ;)
>
>Ну вон фэйсбук сделал конвертор пыха в плюсы в итоге :).А питонисты
>уже показали всему миру с ланчпадом что питон - тормоз, который
>загибается как только нагрузка становится мало-мальски серьезной. Вот честно, ну зае...
>же там таймауты. Почему-то у остальных сервисов невзирая на легионы юзеров
>нет такой жопы.Я не знаю, на каких серверах работает ланчпад. YouTube не тормозит. GoogleMaps и GoogleMail не тормозят. И история знает более девяти тысяч примеров программ на си и си++, которые жутко тормозные.
>Я не знаю, на каких серверах работает ланчпад. YouTube не тормозит. GoogleMaps
>и GoogleMail не тормозят. И история знает более девяти тысяч примеров
>программ на си и си++, которые жутко тормозные.GoogleMaps и GoogleMail северную часть несут на java. питон не упомянут.
>Я не знаю, на каких серверах работает ланчпад. YouTube не тормозит. GoogleMaps
>и GoogleMail не тормозят.А гугль богатый, это 1 из самых богатых контор на планете. :)
>И история знает более девяти тысяч примеров
>программ на си и си++, которые жутко тормозные.История также знает пример PHP -> C++ конвертора от фэйсбука :). Питон даже без jit компилера - ему просто не с чего быть быстрым. Да, оптимальный алгоритм на скриптоязыке может сделать плохой алгоритм на сях. И что это доказывает? Тем более что обычно на скрипоязыках пишут тогда когда на оптимальность алгоритмов - до балды по тем или иным причинам.
юзал систему мониторинга на питоне Zenoss - так это такой мрак по производительности....
Почти все здесь можно как-то разумно объяснить, но питон это какая-то провокация.
Удивительно, сколько собралось дилетантов, орущих про неправильный выбор языка разработки :)Python рулит, потому что на нем пишутся надежные, легко сопровождаемые и расширяемые системы. И, что тоже немаловажно - за конечное время.
>Удивительно, сколько собралось дилетантов, орущих про неправильный выбор языка разработки :)
>
>Python рулит, потому что на нем пишутся надежные, легко сопровождаемые и расширяемые
>системы. И, что тоже немаловажно - за конечное время.Ну нельзя же так толсто !
"Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers"Cuong Do, Software Architect, YouTube.com.
Собственно BIND 10 начало конца питона. Когда будет середина конца, к этому времени сдохнет PHP и будет вытеснено питоном.
>сдохнет PHP и будет вытеснено питоном.Угу, юниксам тоже смерть предсказывали. Лет так 100500 назад.
>Удивительно, сколько собралось дилетантов,Да, все пи...сы а вот anonymous - Д`Артаньян!
>орущих про неправильный выбор языка разработки :)
А что, питон для системного сервиса это нормально? oO
>Python рулит, потому что на нем пишутся надежные,
Надежные? А что ж лаунчпад через раз икает таймаутами? Нихрена ж себе надежность.
>легко сопровождаемые и расширяемые системы.
Ну идите чтоли сопроводите уже лаунчпад, чтобы он не икал таймаутами постоянно, а? А то задолбало! Даже сорцы вроде открыли. Ну, слабо показать миру что питон - не тормоз? :)
>И, что тоже немаловажно - за конечное время.
Да, конечно, надо писать системные сервисы по логике применяемой для написания бизнес крапа. Правда вот боюсь что результат не очень понравится, имхо. Потому что в бизнес крапе ради скорости написания жертвуют всем и вся. Скорость? Да фигня, серверов докупят, бизнесмены богатые. Глюки? Да ничего, лишь бы как-то работало. Совсем без софта заказчику еще хреновее. Дыры? Ну, дыры. И что? Все-равно заказчик уже заплатил. Кого колебет чужое горе?
>А что, питон для системного сервиса это нормально? oOДа. У тебя по этому поводу комплексы?
>А что ж лаунчпад через раз икает таймаутами?
>Ну идите чтоли сопроводите уже лаунчпад, чтобы он не икал таймаутами постоянно,
>а? А то задолбало! Даже сорцы вроде открыли.Пятнадцатый раз одно и то же твердишь. Понимаю, с аргументами-то туго.
>Ну, слабо показать
>миру что питон - не тормоз? :)Уже показано.
>>И, что тоже немаловажно - за конечное время.
>
>Да, конечно, надо писать системные сервисы по логике применяемой для написания бизнес
>крапа. Правда вот боюсь что результат не очень понравится, имхо. Потому
>что в бизнес крапе ради скорости написания жертвуют всем и вся.
>Скорость? Да фигня, серверов докупят, бизнесмены богатые. Глюки? Да ничего, лишь
>бы как-то работало. Совсем без софта заказчику еще хреновее. Дыры? Ну,
>дыры. И что? Все-равно заказчик уже заплатил. Кого колебет чужое горе?
>У тебя точно комплексы :)
>У тебя точно комплексы :)Ай-ай-ай как толсто...
>>А что, питон для системного сервиса это нормально? oO
>
>Да. У тебя по этому поводу комплексы?
>Может и примеры приведешь?
>Да. У тебя по этому поводу комплексы?Нет, у меня по этому поводу предпочтения чтобы сервисы жрали минимум ресурсов, обладали минимумом зависимостей, были минимального размера и т.п.. Почему так? Потому что ресурсы стоят бабла а чем монструознее, тем глючнее, дырявее и проблематичнее в целом. Да и чем меньше дерьма в системе - тем меньше обновлений, грабель и проблем. На кой хрен мне головная боль как вон у тех гентушников при смене версий питона, а? Если питонисты считают что все готовы нянчиться с их тормозным любимцем как они сами и прощать ему все его минусы - они напрасно так думают.
>Пятнадцатый раз одно и то же твердишь. Понимаю, с аргументами-то туго.
Ну, вы то и такого не осилили, для начала. Так что кивать "сам дурак" - как-то некузяво.
>Уже показано.
Где и кем? oO Мне вот не попадалось пока не тормозных вещей на питоне. А уж системный сервис на этом - мать-мать-мать, энтерпрайзненько, ать-ать-ать. Еще б на шелскриптах написали.
>У тебя точно комплексы :)
Судя по конструктиности вашего комента комплексы конечно есть, но не у меня...
>Нет, у меня по этому поводу предпочтения чтобы сервисы жрали минимум ресурсов,
>обладали минимумом зависимостей, были минимального размера и т.п.. Почему так? Потому
>что ресурсы стоят бабла а чем монструознее, тем глючнее, дырявее и
>проблематичнее в целом. Да и чем меньше дерьма в системе -
>тем меньше обновлений, грабель и проблем. На кой хрен мне головная
>боль как вон у тех гентушников при смене версий питона, а?
>Если питонисты считают что все готовы нянчиться с их тормозным любимцем
>как они сами и прощать ему все его минусы - они
>напрасно так думают.Да что ж ты так напрягся-то? Не нравится тебе - все уже поняли, уймись :)
Не хочется уже аргументы приводить. Видно, что ты еще больший фанатик, чем я. Успехов тебе с твоими идеальными хэллоуворлдными вакуумносферическими Системными Сервисами! ;)
P.S. Нет, все-таки не могу не процитировать: "ресурсы стоят бабла а чем монструознее, тем глючнее, дырявее и проблематичнее в целом". Python вместо C++ это априори менее глючно и дыряво, потому что нет проблем переполнения буфера, неинициализированных переменных, выхода за границы массива, использования освобожденной памяти и т.д... Это обычно менее монструозно и проблематично, потому что не требует сборки, работает на любой системе и сопровождается в разы легче.
Понимание сути обсуждаемого вопроса и представление о причинно-следственных связях у тебя напрочь отсутствуют.
>Python вместо C++ это априори менее глючно и дыряво, потому что нет проблем переполнения буфера, неинициализированных переменных, выхода за границы массива, использования освобожденной памяти и т.д... Это обычно менее монструозно и проблематично, потому что не требует сборки, работает на любой системе и сопровождается в разы легче.Вызывать он все равно будет код на C++, значит в безопасности выигрыша нету.
Зато есть куча левых обвязок чтобы код на C++ взаимодействовал с собой же через Python.
В итоге получаем такую же или худшую безопасность, усложнение кода, лишние тормоза и гипотетически большую гибкость если закладываться на то что под это API будут писать какие-то сторонние разработчики (что как я понимаю не предполагается).
Вообщем не ясно на кой все это.
>Да что ж ты так напрягся-то?То что видимо придется сваливать на иной сервак с более разумным вектором развития чем ЭТО.
>Не нравится тебе - все уже поняли, уймись :)
Ну, надеюсь что вам понравится и что команда ISC будет стараться не зря.
>Не хочется уже аргументы приводить.
Понятно - внятных аргументов нет, поэтому...
>Видно, что ты еще больший фанатик, чем я.
...поэтому скатываемся на троллоло.
[толсто, выпилено]
>Python вместо C++ это априори менее глючно и дыряво,
Вообще-то там питон ВМЕСТЕ с C++, мистер лолка. Если бы там все было на питоне - весь топ500 был бы разобран под днс-сервера :)
>потому что нет проблем переполнения буфера, неинициализированных переменных,
>выхода за границы массива, использования освобожденной памяти и т.д...Угу, только во первых юзаются сишные куски т.к. скорость самого питона в большой заднице, а во вторых, у питона своих проблем есть. Там вам и ломка совместимости версий, и тормознутость, и лишние зависимости, и явно энтерпрайзный подход к вопросу. Кстати, заметьте: большая часть уязвимостей в днс были на уровне логики протокола, а вовсе не переполненя буферов или ошибки выделения памяти. Более того - в скриптоязыках конечно нет переполнений буферов но если посмотреть на списки уязвимостей скажем вебприложений - становится понятно что это в итоге не сильно помогло.
>Это обычно менее монструозно и проблематично, потому что не требует сборки,
>работает на любой системе и сопровождается в разы легче.Угу, конечно. Могу себе представить насколько проще, легче, безбажнее и прочая будет смесь питона с си++, ага. Глядючи на бинд9 как превью чего ожидать от данной команды програмеров. Поэтому заранее поищу себе замену т.к. мне действительно хочется чтобы серваки просто работали. А вот плясать с бубном по поводу версий питонов и грабель всяких монстрил - неохота.
>Понимание сути обсуждаемого вопроса и представление о причинно-следственных связях
>у тебя напрочь отсутствуют.Наверное именно поэтому вы не привели ни 1 вменяемого аргумента?
ага, особенно для embedded
процессорное время стоит дешевле человеко-часов. а языком трепать каждый может, а есть ли среди недовольных реально квалифицированные люди которые не ценят своё время, чтобы взять и переписать это на си?
>процессорное время стоит дешевле человеко-часов. а языком трепать каждый может, а есть
>ли среди недовольных реально квалифицированные люди которые не ценят своё время,
>чтобы взять и переписать это на си?Ваша наивность поражает. Почему на питоне не написан MySQL, Apache? Почему нету ни одного полноценного аудио или видеоплеера написанного на питоне ? Почему все сколько-нибудь востребованные компиляторы и интепретаторы пишутся на компилируемых языках ?
>>процессорное время стоит дешевле человеко-часов. а языком трепать каждый может, а есть
>>ли среди недовольных реально квалифицированные люди которые не ценят своё время,
>>чтобы взять и переписать это на си?
>
>Ваша наивность поражает. Почему на питоне не написан MySQL, Apache? Почему нету
>ни одного полноценного аудио или видеоплеера написанного на питоне ? Почему
>все сколько-нибудь востребованные компиляторы и интепретаторы пишутся на компилируемых языках ?
>Если уж говоришь с такой уверенностью, разбирайся хотя бы в вопросе.
Как насчет Exaile, Deluge, PiTiVi, Decibel, BitTorrent, Mercurial? И при чем тут интерпретаторы-то вообще? Расскажи, почему в веб-приложениях ни один здравомыслящий разработчик не будет использовать си?
>>Если уж говоришь с такой уверенностью, разбирайся хотя бы в вопросе.
>>Как насчет Exaile, Deluge, PiTiVi, Decibel, BitTorrent, Mercurial? И при чем тут >>интерпретаторы-то вообще? Расскажи, почему в веб-приложениях ни один здравомыслящий >>разработчик не будет использовать си?В вопросе не разбираетесь именно вы: Exaile и PiTiVi - по большому счету морда для gstreamer'a и других библиотек по работе с аудио, оба эти проекта можно было написать на перле или тикле - они так же были бы всего лишь клеем между уже существующими библиотеками.
Почему-то рекомендуемым клиентом для торрентов стал mTorrent(правда только под Windows), написанный на С, а не ваш BitTorrent ? И причем здесь mercurial ?
Нет уж, уважаемый, вы мало того, что не разбираетсь в вопросе, так ещё и приводите примеры ни коим образом не относящиеся к поставленному вопросу. Признайтесь, что вы просто очередной фанатичный питонщик и мы прекратим этот бессмысленный спор.Скорость разработки и неприспосбленность С для веб-проектов, не дают его эффективно использовать в данной нише.
А вы мне теперь не расскажите почему, когда разработчики ваших веб-приложений упираются в производительность, начинается переписывание ресурсоемких кусков кода на С ?
>Почему-то рекомендуемым клиентом для торрентов стал mTorrent(правда только под Windows),
>написанный на С, а не ваш BitTorrent ?Потому что прожка в 300 кило весом умеет в 100500 раз больше чем то убогое говно на питоне которое было, не требует переть юзеру в его систему вагон рантайма и не тормозит. Потому ее и купили авторы битторента - технологическое преимущество было вопиюще, как тузик vs грелка.
>Ваша наивность поражает. Почему на питоне не написан MySQL, Apache? Почему нету
>ни одного полноценного аудио или видеоплеера написанного на питоне ? Почему
>все сколько-нибудь востребованные компиляторы и интепретаторы пишутся на компилируемых языках ?Почему все высоконагруженные сайты пишутся на скриптовых языках.... Если бы вы участвовали в создании сайта обрабатывающего больше тысячи одновременных запросов к динамике, вы бы так не говорили. Bind на python пишут примерно по той же причине.
>Почему все высоконагруженные сайты пишутся на скриптовых языках....Все говорите ? :)
Видимо про java и asp.net вы не слышали. Или вы, простите, кроме "сайтов" ничего не видели ?>Если бы вы участвовали в создании сайта обрабатывающего больше тысячи одновременных запросов к динамике, вы бы так не говорили. Bind на python пишут примерно по той же причине.
С такими ляпами я сомневаюсь, что и вы писали нечто подобное. Сравнивая DNS-сервер и "сайт", вы подразумеваете, что первый как и последний должен для решения проблем производительности использовать горизонтальное масштабирование. Это малоприемлемый подход для сервиса такого уровня.
>Почему все высоконагруженные сайты пишутся на скриптовых языках....Да, наверное именно поэтому фэйсбука недавно выпустила транслятор пыха в си++ :).При том в кризис это прям тенденция - изучать вопрос как масштабироваться иными методами чем докупка серверов.
Я согласен что вариант на C будет использовать меньше ресурсов, и я буду Вам лично очень признателен если вы его перепишете. Разработчики выбрали питон, и осуждать их приходите когда Вы напишите на C тоже самое.
Вспоминается, как опозорился Xandros, переписав скрипты для инициализации сервисов с shell на Си в своей версии дистрибутива для EeePC :-) Регулярные выражения, обработка строк и хэши на Perl будут в большинстве случаев работать быстрее, чем вы сможете написать на Си.
Вначале хотел ответить персонально User294-му ... но тут прям трэнд наблюдается :)Народ смутил питон. Меня тоже - слегка :) Сходив по ссылкам (да, я в курсе что это !Ъ) - объяснений не нашёл. Ну разве что общие слова типо "The server is written in C++ in certain performance-critical parts and in Python."
Мысли по поводу:
- _правильно_ сделанный не должен тормозить из за питона. Crunchers то все на плюсах ... (См. гугель)
- производительность как я понял будет браться экстенсивно - увеличением числа нод в кластере.
- как они это и в эмб. планируют яхз. Разве что :
- может быть они всё же _прототип_ на питоне делают? Хотя вряд ли ... :)- Ну и главное: что - то будет! Поживём - увидим :)
>- производительность как я понял будет браться экстенсивно - увеличением числа нод
>в кластере.Ну, картина в общем ясна - будет огромное монструозное энтерпрайз-тормозилово работающее по принципу "докупите еще серверов". Это знакомая фигня, только я не понимаю зачем системный сервис писать по принципу бизнес-логики :).ISC знает? Ну флаг им в руки и барабан на шею, спасибо что заранее предупредили что на их решени лучше не закладываться (а, простите, много ли серверов в мире, нагруженность которых вообще требует бубухать деньги в кластер и при том сугубо по причинам производительности?).
Как минимум - мне такой вектор развития DNS сервака никуда не уперся и лично я уже начинаю присматривать что-то с более вменяемым вектором развития и менее станным подходом к написанию системных сервисов.
>будет огромное монструозное энтерпрайз-тормозилово работающее по принципу "докупите еще серверов"Масштабирование вширь на порядки ценнее масштабирования ввысь, это даже школьники должны знать.
Ну да, DNS сервер для которого объективно хватить первопня, теперь будет переписан на питоне и потребудет масштабирования вширь. Ценно, нечего сказать. Полностью в духе модных технологий.
>- как они это и в эмб. планируют яхз. Разве что :я думаю что они расчитывают что на эмб скоро будут 4 ядра по 2 ггц ставить и 6 гиг мозга
Что-то мне уже страшно стало от планов ICSМы посмотрели на pdns, и решили сделать свой, но с блекджеком и шлюами :)
Даешь дальше круче, бинд 11 будет написан на bash, а бинд 99 будет написан на бумажке, кривым почерком и от руки.
Я конечно за то что бы dns сервер был лёгкий и быстрый, проэтому считаю что c и asm для высоконагруженных приложений лучше. Но я думаю тут дествительно временной и денежный вопрос стоит для написания того или иного функционала, который мне возможно не понадобится и полагаю я всегда смогу использовать 9ю версию которая меня в полне устраивает.
to Аноним2: скрипты на сайтах пишут зачастую на python,php,perl для получения максимального функционала за короткое время, а также возможности контроля выполнения этих приложений на уровне http сервера (mod_python,mod_php,mod_perl).
Немного не в тему. Нужен авторитативный DDNS+DHCP, 1 зона. Как я понимаю, dnsmasq не подойдет. Есть альтернативы связки dhcpd+Bind?
to Zamir:
Ты, когда писал свои длинные предложения, какой программой-переводчиком пользовался? Если не можешь писать по-русски длинные предложения. Пиши простые, короткие и ясные. Какой смысл умничать, если ты даже вокруг "конечно" запятые не поставил.
похоже они готовятся к этому:
Google хочет изменить DNS-систему
http://nag.ru/news/newsline/17639/google-hochet-izmenit-dns-...
Google и Neustar хотят, что бы рекурсивный сервер мог передавать авторитативному часть информации о пользователе, в том числе его IP-адрес.В первую очередь, это должно помочь владельцам интернет-сервисов с распределенной инфраструктурой предоставлять пользователям доступ сразу к ближайшему дата-центру, без обращения к центральному узлу.