Алексей Сундуков

>В чём же тогда прелесть Redis-а?
Данные всегда в ОЗУ, когда как в РСУБД индекс может быть вытесняться на диск, данные при этом на больших объемах почти всегда на диске. Поэтому и получаем просадку производительности из-за I/O на диске. В Redis это в принципе нет, они сейчас на сколько я помню от виртуальной памяти отказались. Про О(1) Ghostwriter уже сказал. ACID таки вносит свой оверхед.

Ну и из подобной группы ПО его выделяет условная персистентность.

Если цель без проблем получать из за бугра заработанные деньги вбелую, то открытие ИП без вариантов. К слову по налоговой нагрузке в этой случае у нас все на самом деле очень хорошо. Сильно лучше, чем для физического лица (налогообложение которого на самом деле далеко не 13%).

Хм… а не проще как-то договориться о сменной работе в духе как нефтяники или моряки? Просто я так понимаю, что по прошлому опыту работы позиции в плане ЗП были неплохие. Но на новом месте просто не нужные такие специалисты и ЗП низкая соответственно. Но в случае перепрофилирования позиции будут абсолютно теми же ибо прошлые скилы тут врятли помогут (на уровень ЗП точно не повлияют) и на первом этапе это будет ЗП уровня джуниора. Не знаю как в вашей локации, а в нашей 30-летний джуниор синоним неудачника. Я это упоминаю к тому, что может получится психологически очень тяжело. Стоит ли оно того?

Мне кажется при таком раскладе, когда Motivate Clock почти во всем устраивает, проще отписаться авторам Motivate Clock запросив эту фичу.

P.S. Сам тупо пишу на бумажке время «простоя».

Jabber без вариантов. Для организации есть такая полезная штука как shared roster. Пришел новый человек, добавили его туда, он появился в контакт листе у все. Снимает вечное «у нас в отделе Х новый человек, вот его контакты, добавьте».

www.google.com/search?q=set+names&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ru:official&client=firefox

P.S. Подобная песочница есть даже для PHP.

В контексте PHP+MySQL выбор очевиден — ejabberd. Чат в ипостаси джаббера есть и уже готовый из коробки. Под него даже готовые браузерные клиенты в духе JWChat есть: www.ejabberd.im/jwchat-localserver

P.S. А про «дешевый харед хостинг» в разрезе «запускаем онлайн бизнес» не смешите. В наше время взять VPS с root доступом можно за 200-300 руб/мес. Такой бюджет по силам даже студенту.

Помниться Сысоев в рассылки по nginx упоминал, что количество воркеров можно выставлять равным количеству ядер, но увлекаться этим не стоит, т.к. из-за перемещения в процессе работы по ядрам эффективность может падать. Поэтому в первом приближении стоит все же ориентироваться на количество ядер.

Не очень четкое описание, но может это был мегаплан?
megaplan.ru

Когда модемы были еще живы и за каждый мегабайт приходилось платить, то я много каких качалось перепробовал. teleport в том числе. Но в итоге оказалось, что получить нормальный результат практически на любом сайта позволял только Offline Explorer. Им много лет и пользовался. Там что удобно, встроенный браузер. Через него бродишь, если страница не скачана, то там висит специальная страница с вопросом, будем ли качать. Жмакаем да и через пару секунд обновляем. Скачанный страницы он сохраняет в заранее заданную папку которую можно было скопировать и притащить домой. Причем сохранял структуру как на сайте.

Прогой давно уже конечно не пользуюсь. Сейчас специально глянул, проект по прежнему жив. Не знаю, на сколько он остался адекватным в наши дни, но, имхо, попробовать воспользоваться все же стоит: www.offlineexplorerpro.com/

Разумнее всего подобрать просто PHP фротенд к какому либо торрент клиенту: www.google.com/search?q=torrent+dht#hl=en&sclient=psy-ab&q=php+torrent+client&oq=php+torrent&aq=2&aqi=g4&aql=&gs_sm=1&gs_upl=0l0l1l643l0l0l0l0l0l0l0l0ll0l0&gs_l=serp.1.2.0l4.0l0l1l643l0l0l0l0l0l0l0l0ll0l0.llsin&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=bfbad756b3e0f08f&biw=1280&bih=816

1.
а) На уровне TCP:
Клиентский процесс умер, но хост клиента жив, значит TCP стек клиента в ответ на данные идущие с сервера отправит FIN. TCP сервера получит его, пошлет в ответ ACK и из ESTABLISHED перейдет в CLOSE_WAIT. После того как рабочий процесс сервера сделает close TCP стек сервера пошлет FIN и перейдет в LAST_ACK дожидаясь ACK от TCP клиента. Получив его перейдет в CLOSED.

Тут у нас длительность этого процесса зависит от того, на сколько быстро бегают у нас пакеты между хостами. Учитывая размеры, то как правило быстрее, менее секунды.

б) На уровне приложения:
Не знаю, чем пишет PostgreSQL в сокет, но в любом случае при попытке записи в сокет который перешел в CLOSE_WAIT рабочий процесс получит ошибку. write по идее должен завершиться с ошибкой EPIPE, после чего рабочий процесс должно сделать close, хотя может завершится и без этого, ядро фоном это сделает само. В первом приближении все должно происходить быстро и без задержек.

P.S. Описания добавленные в уточнении вопрос противоречат первоначальной формулировке вопроса. Не полученный отлуп к клиента это проблемы с сетью или хостом клиента, но в случае умирая процесса клиента TCP стек клиента по прежнему работает и он берет на себя функции уведомления хоста сервера об ошибке поэтому все происходит достаточно быстро.

Ни каких проблем с созданием шаблонов там нет, все банально на smarty.

Интеграция там тоже делается вполне себе неплохо. Я проект blog.pravo.ru интегрировал с docs.pravo.ru через блог blog.pravo.ru/blog/docs/. Каменты к документам в blog.pravo.ru автоматически создают новый топик в этом блоге. Каменты написанные в этом блоге в реальном времени видны и в docs.pravo.ru. Можно так же создать в этом блоге топик и камент к нему в реалтайме появится в docs.pravo.ru. При том, что системы абсолютно разные и по сути слабо связанные интеграция прошла вполне нормально.

Новый функционал тоже хорошо допиливается. Я добавлял разделы Работа и Компании таким образом, что можно указывать кто из пользователей блога является владельцем компании. Тогда он может добавлять список работников в том числе указывая юзеров блога.

В общем у меня о движке только положительные впечатления, он вполне достойное ПО которое можно как угодно в рамках своей ниши кастомизировать уже готовое + напилить своего. Из минусов пожалуй отмечу только многословность. Нужно дописывать большие куски кода + нет каких-то готовых типовых блоков которые можно было бы взять за основу и быстро подпилить. В общем рекомендую, как блоговая платформа это хороший выбор. Лично для себя в итоге выбрал пилить свое. Что бы и работало быстрее и разработка новых фич занимала меньше времени.

Причина однозначно внутри вашей сети. И тут два варианта. Либо кто-то намеренно ломает arp, либо на одной из машин вирус просто. Для сетевого админа это все всё равно сводится к одному варианту, одна из 50 тачек пытается заниматься спуфингом. Если не известно точно, какие из них, то писать сетевой график и потом анализироваться в том же ваершарке, если машина точно известна и при это антивири молчат, то лучше переустановить.

Я бы

SCRIPTNAME=/etc/init.d/$NAME

заменил на

SCRIPTNAME=`readlink -m $0`

Потому как если сменить NAME, но не изменить имя файла, то можно получить ошибку при использовании SCRIPTNAME переменной. Сейчас же она в реальности она не содержит в себе данных заложенных в смысл имени.

А разве у json может быть какая-то особый формат (не беря во внимание JSON Schema)? json контейнер, что туда набили то там и есть. В этом смысле приведенный пример самый обычный json без каких либо «аналог».

В общем я крайне рекомендую прочесть книгу "UNIX: разработка сетевых приложений" Стивенсона. Имхо, гениальный труд который одинаково хорошо использовать и как учебник, и как справочник.

>А если фтп в активном режиме?
Да не важно. При активном в состоянии LISTEN висит сокет на клиенте, на сервере он будет в SYN_SENT первоначально, но до ESTABLISHED не дойдет, ибо фаер ему это не даст сделать.

Если не секрет, сколько предлагаете? Я к тому, что слово «быстро» автоматически добавляет к цене ХХ% сверху. Ибо срываться из офиса на новое место работы человек врят ли будет если только ему не предложат больше денег. Или какой-то мега интересный проект.

Может стоило бы посмотреть как временное решение в сторону фриланса? Сходит на oDesk к примеру. При этом продолжать искать нужного человека, но уже без «быстро».