Я не ковырял софт, озвучивающий текст, однако полагаю, что звуковые капчи легче распознать. Достаточно набрать базу паттернов звуко-символов и сравнивать спектрограммы.
А если я проголосовал за "Не использую телефон", то что, мой голос уйдёт вникуда? Или как у нас в стране на выборах: голоса за партии, получившие менее 7% голосов раскидываются на партии, одолевшие этот барьер (то есть, твоё мнение не учитывается; если голосуешь за непопулярную партию, то твой голос в конечном итоге уходит популярной, нравится/хочется тебе этого или нет)?
> Проблема большинства web-проектов - это черезмерная
> нагрузка на SQL-сервер...
> А вот если вы переросли одну машину с SQL-сервером -
> тут уже и до необходимости использовать C/C++ недалеко...
Те же яйца, но в профиль. Если SQL-сервер сильно нагружен, то тут и Си ему не поможет. Си только обработает данные быстрее. А извлечёт он их из БД с той же скоростью что и другие языки.
По-моему, абсолютно очевидно, что на Си почти всё будет быстрее. Однако "почти" — это не значит, что всё. Скорость и сложность разработки web-приложений на Си оставляет этот язык далеко позади PHP и прочих, специально заточенных для web, языков. На Си невыгодно писать программы с малым сроком жизни.
Если сайт или его часть работает медленно, то прибегают к оптимизации кода. Если оптимизация не помогла, то прикручивают всякие ускорители и кеширующие инструменты. Если и это не помогает, то тут разработчики ещё очень крепко призадумуются, стоит ли часть функциональности перекладывать на плечи Си или проще и дешевле обновить сервер...
Почему дешевле, да потому, что время Си-программиста стоит гораздо дороже PHP-программиста.
Так что сравнения "C vs PHP/Ruby/JSP/... для web" изначально некорректны и однозначно Си останется в проигрыше (хотя бы потому, что предназначен он для решения других задач).
Да, не спорю, для собственного развития можно попрактиковать такой подход. Но в крупных, динамически развивающихся проектах, когда код одного файла в течении дня может поменяться почти полностью (причём несколько раз), Си делать нечего. С ним разработка пойдёт гораздо медленнее, хотя вроде делов-то всего ничего — отредактировать исходник и две секунды на компиляцию... уж поверьте.
AIM смахивает на AOL Instant Messenger. Я почему-то подумал что тут будет описана история создания этого клиента )). Кстати, кто такие корпоративные паразиты?
php_flag magic_quotes_gpc Off
php_flag register_globals Off
Остановок "тута" и "здеся" на маршруте нету!
> нагрузка на SQL-сервер...
> А вот если вы переросли одну машину с SQL-сервером -
> тут уже и до необходимости использовать C/C++ недалеко...
Те же яйца, но в профиль. Если SQL-сервер сильно нагружен, то тут и Си ему не поможет. Си только обработает данные быстрее. А извлечёт он их из БД с той же скоростью что и другие языки.
Если сайт или его часть работает медленно, то прибегают к оптимизации кода. Если оптимизация не помогла, то прикручивают всякие ускорители и кеширующие инструменты. Если и это не помогает, то тут разработчики ещё очень крепко призадумуются, стоит ли часть функциональности перекладывать на плечи Си или проще и дешевле обновить сервер...
Почему дешевле, да потому, что время Си-программиста стоит гораздо дороже PHP-программиста.
Так что сравнения "C vs PHP/Ruby/JSP/... для web" изначально некорректны и однозначно Си останется в проигрыше (хотя бы потому, что предназначен он для решения других задач).
Да, не спорю, для собственного развития можно попрактиковать такой подход. Но в крупных, динамически развивающихся проектах, когда код одного файла в течении дня может поменяться почти полностью (причём несколько раз), Си делать нечего. С ним разработка пойдёт гораздо медленнее, хотя вроде делов-то всего ничего — отредактировать исходник и две секунды на компиляцию... уж поверьте.
Я бы себе на сайт не поставил такие иконки.