Как стать автором
Обновить
-1
0
Дмитрий Устюжанин @dmitryus

Пользователь

Отправить сообщение
Звиняюсь, ссылку криво написал. Вот:
pesikot.org/static/google_sms.html

Кстати юзаю уже года три наверное — работает как часы.
Бесплатно на свой номер можно через гуглокалендарь — настраиваите там уведомления о событиях по sms — а дальше через гуглоапи календаря шлете себе смски — вот пример моего скриптика для всяких уведомлений с сервера
pesikot.org/static/google_sms.html
один кочегар и 10 мешков угля
не уверен насчет незамутненности
избави меня бог от таких админов…
Вы сначала разберитесь в отличиях ОС, потом постарайтесь разобраться как устроены разные fs, научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск (кстати этим страдает стандартная конфигерация Gutsy).
В общем вопрос надо не изучать — а проводить стресс тесты и манипулируя параметрами базы, апача, нгинкса и ядра системы учиться на практике.
да в общем бред… поменяли тут, переписали там, это не сервер-сайд оптимизация а переписка движков, если бы были приведены примеры оптимизации и изменения этоих движков, ей бы цены не было. А так просто самопиар, и желание услашать «восторг публики».

В общем седьмая вода на киселе.

Ну а когда все дорвейщики и прочие недобросовестные спамеры туда перенесут свои домены. Гугль сможет их разом выкинуть из выдачи :)
«Держи друга близко а врага еще ближе»
Ему разницы нет — но на боевом сервере например запуск апача до старта мускуля иногда приводит к сильному проседанию первого из за потока запросов от клиентов на которым он (точнее не он естественно а скрипты сайта) выдает ошибки соединения с БД — но пред эти мужительно пытаясь достучаться до мускуля. — Количество апачей может подскочить до максимального за буквально 1 секунду. И на разгребание запросов при большой нагрузке может уйти до 15-30 минут.
В общем ИМХО не корректно не по порядку запускать зависящие друг от друга вещи.
Тогда я понял правильно, но мне казалось что таких случаев быть не должно. И у меня например ни на одном дистрибутиве это не попадалось. Так что вряд ли это даст большой прирост скорости ИМХО
упс. извиняюсь. не о том подумал
Вы имели ввиду runlevel? но там есть опасность не корректного запуска зависимых скриптов. -тотже банальный LAMP не очень корректно запускать не по порядку
а где вы видели стартовые скрипты с одинаковым уровнем выполнения?..
И не надо тешить его самолюбие, самый простой способ остановить истерику это не обращать на истерящего внимания.
гхм…
Если индивидуум думает что программирование (даже правильное) это цель то наверное пора идти в дворники. Программирование это инструмент а не цель.

А знает ли этот человек чего он хочет от жизни? Я что то в этом сомневаюсь.
Жалко, специалист наверное неплохой, но сотрудника такого увы иметь в команде не хотелось бы.
В общем не понимаю за что плюсуют. Чел просто сдулся, гордиться тут нечем.
Согласен, как можно больше вариантов синхронизации, с гугл календарем тоже хотелось бы.
Отправка задач по почте в формате аутлука, думаю это будет менее затратный но не менее удобный вариант.
Ну правда сколько можно — Если вы за открытый софт и протоколы — пользуйте жаббер и оставьте ICQ в покое.
Это проприетарный софт и проприетарный протокол.

Статья действительно ни о чем, одна вкусовщина. Для вас же не будут убещительными доводами такие фичи в icq как extraz и tzers. Потому что вам мессенджер нужет только для общения, ICQ нацелен на более широкую аудиторию.
Все это холивары. Пользователь линукса по определению не может любить ICQ.
Хотя я наверное исключение :)
Ну в общем у меня тоже грубовато получилось…
ну вот обязательно найдется человек которому скучно но при этом вместо того чтобы сесть и придумать хотя бы велосипед будет со скуки с… ть в комментах с умным видом, «просто от желания чего нитиь этакое» умное сказать.
Вообще я хотел сказать о скорости работы конечного приложения.
ООП и быстродействие вещи не свместимые.
Ни один транслятор или компилятор не сделает из ООП кода — машинный код сопоставимый по объему с тем же функционалом но написаным в обычной «функциональной» нотации.
И даже скорость разработки не причем, ООП это удобство и скорость разработки сложных систем, но для 80% задач это не рационально.

Извиняюсь за «холиварность» коммента.
Эххх. жалко что почти ушло это время. А в прочем я до сих пор парсеры и временные инструменты пишу на нем. PERL FOREVER!

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность