shadowalone

www.slideshare.net/CiscoRu/cisco-9691290

это /etc/motd, его обновляет /etc/cron.d/update-motd

Наверное потому что это никому не надо. Если вам надо сразу же после того, как вы сделали фото, залить его, скажем, на фотохостинг какой-то или в соц сеть — то для этого есть какие-нибудь приложения (не уверен но скорее всего должны быть).
А так это вопервых не нужно, а во вторых будет захламлять и без того сочащийся стандарт HTML5.

Добрый день.
Если и правда пользователи давали согласие на рассылку почты при регистрации, я бы на вашем месте не тратил ресурсы вашего сервера, смтп гугла, а также время, которое требуется на написание скрипта.

www.mailchimp.com/ — дороже;
www.marketion.ru/ — дешевле (http://www.marketion.ru/price.html — тарифный план М1, копейки вообще; а если у вас стартап — так и вовсе бесплатно).

Зато все качественно, быстро и без изобретения велосипедов.

Я вам поставлю + просто за то, что вы первый кто напишет пост о том, что я изучил первым делом :)

Выбора особого нет это или ejabberd, openfire или tigase. Можете посмотреть сюда: en.wikipedia.org/wiki/Comparison_of_XMPP_server_software
Первый — наиболее распространен. Он быстрый, классно распаралелливается(не зря на erlang написан) и поддерживает весьма обширное количество ХЕРов. Основной недостаток — мало кто знает erlang)
Openfire — удобная настройка, всякие гуи и прочая, но сильно проседает производительность при большой нагрузке. Идеален для небольших сетей.
tigase — так же как и openfire написан на яве, но куда лучше масштабируется, да и вообще пишется именно с упором на производительность. С другой стороны в последний раз когда я на него смотрел он поддерживал куда меньше плюшек и там были проблемы с документацией.

По поводу того, что почитать — www.ejabberd.im/ www.igniterealtime.org/projects/openfire/ www.tigase.org/
Там есть достаточно подробная документация, мэйл листы и исходники, последнее пожалуй самое полезное)

А вообще не очень понятно зачем вам серверная часть, если вы пишете клиентскую.

Спасибо что подсказали такие хоткеи для виндовса )

Любой спрей для мониторов+мягкий кусочек замши. Выглядит как новый

Вы ничего не недоговариваете? Сколько на балансе денег? «На балансе осталось 10 рублей» (а значит, все услуги предоставляются как обычно, и вы можете делать с данными что угодно ещё месяц), или таки «денег на аккаунте нет»/«на балансе нет средств»/«понятно что сайт они и так выключили» (а значит, к моменту очередной оплаты у вас было 10 рублей, но вы просрочили оплату, а значит, на самом деле у вас на балансе -140 рублей?)

Если первое — то это какая-то фигня, так не бывает, чтобы баланс положительный, а и сайт отключили, и доступ к файлам убрали. Так не подставляются.

Если второе — то… по-моему, принцип «нет ножек — нет и печенек» является вполне очевидным, чтобы не ожидать, что ваши файлы будет кто-нибудь хранить бесплатно. Конечно, у приличных хостеров есть политика, что делать при неоплате, но вообще это всё основано на доброй воле хостера.

В общем и целом — хостинг прав. Как по духу, так и наверняка по договору (если не совсем идиоты его писали).
Тут же всё просто как батон за 13 копеек — у Вас не оплачены их услуги, поэтому и них нет оснований Вам какие-то услуги оказывать. Они вообще имеют право уничтожить Ваши данные в любой момент.

Максимум что они обязаны в этой ситуации, это вернуть Вам Ваши 10 рублей. Но и то это только в том случае, если их договор подразумевает, что при недостаточном балансе деньги не списываются. Иначе может получится еще хуже — у Вас на балансе будет минус 140р, которые Вы должны будете оплатить.

Откройте для себя DropBox

Нет, хотя бы потому, что если верить Интернету, то там используется коннекторы RJ48 а в них — 10 жил:) не говоря уже о разной модуляции, кодировании и логики. Если вам нужен еще один Ethernet порт, купите Switch с VLANами и используйте Sub интерфейсы

perl killapache.pl security-corp.org 500 /robots.txt
host seems vuln
ATTACKING security-corp.org [using 500 forks]
:pPpPpppPpPPppPpppPp
ATTACKING security-corp.org [using 500 forks]


Понеслась. Кто поможет?

<meta name="generator" content="DataLife Engine Nulled by M.I.D-Team (http://www.mid-team.ws)" />

FOR %F IN (*) DO COPY %F %~nF

Все равно никто ничего не скажет. Поэтому мои предположения:

1) Снижение нагрузки на DNS.
за: на каждое обращение к профилю юзера выполняется лишний ресолвинг. вносит задержки. лишняя нагрузка на сеть.
против: новость «как DNS лег под хабрэффектом» хорошо опубликовать первого апреля.

2) >9000 виртуальных хостов сильно огорчили сервер.
за: очень возможно, особенно если они были «брутально» прописаны в конфиге апача.
против: сильно сомневаюсь что оно так. Сотни-то хостинговых кампаний предлагают услуги виртуального хостинга, когда и поболее доменов висит на одном сервере, и чем хабр отличается? Да и высоконагруженные проекты с кучей поддоменов: тоже есть хорошие примеры, ЖеЖешечка например, так же, работает себе, и ничего!

3) Виртуальные поддомены вначале планировались для чего-то еще, типа возможности для хабраюзеров создать свой мини-сайт на хабре. Но потом решили так не делать. А сейчас просто «выпилили нахрен столетний рудимент» во время очередной итерации рефакторинга.
за: иногда код следует перебирать и архитектурно. куча заведомо мертвого кода в проекте — путь в никуда, как жизнь в городе-призраке!
против: только зачем? если рудимент не мешает, то святой принцип: работает-не трогай!

4) Поддомены *.habrahabr.ru хотят дать компаниям под корпоративные блоги (посолидней как-то ведь), а юзеров просто передвинут /users/username/.
за: очень даже возможно. Маркетингово совершенно нелогично когда «компания» имеет какую-то «домашнюю страничку» /companies/thecompany/ а «юзер» получает целый «домен».
против: а компаниям на это пофиг, у каждой из них есть свой корпоративный сайт.

5) Поддомены *.habrahabr.ru хотят отдать под тематические блоги. Каждая тематика-свой поддомен.
за: да, вообще-то логично! более логичнее, чем для юзеров!
против: а смысл?

6) Распределение нагрузки за счет наращивания количества обслуживающих серверов.
за: если определенные юзерские данные были связаны с определенными серверами, то логично.
против: все равно непонятно, если запрос проходит через rewrite то пофиг что домен что кусок пути.

7) Юзеры стали злоупотреблять пиаристыми поддоменами username.habrahabr.ru.
за: а что, *.habrahabr.ru — возможно попробовать как инструмент для раскрутки.
против: «малокалиберно» слишком. тянет на материал для новости на первое апреля.

8) Выкатывание какой-то принципиально новой фишки, где поддомен будет только мешать.
за: неизвестно что это за фишка, может поддомены и сильно будет мешать!
против: а неизвестно что это за фишка, может поддомены и не будут мешать;)

9) Хабр собирается выкатить пачкой сразу кучу хабра-сервисов. Логичное предположение, если ХабраСторадж — только начало, а завта планируется уже ХабраБлекджек.
за: habrastorage.habrahabr.ru для Хабрастораджа более правильно, чем постоянный риск «фишинг-батхертов» вида ha6past0rage.ru. Да и проще с одной кукой авторизации в одном домене.
против: ну, а если какой-то проект предусматирвает «столь тесную интеграцию с хабром», то почему бы не habrahabr.ru/projectname/?