Pull to refresh
70
Никита я@differentlocal

Затрудняюсь ответить :(

18
Subscribers
Send message
/me представил 309 человек детей, пишуших код на C++ под FreeBSD и читающих в соседнем окне Хабр. Брр.
Это и есть ошибка планирования каналов.

Запуская трекер стоило подумать о возможном росте трафика и его предусмотреть.
>Вспоминаются кабельное тв, домофоны. :)

А еще там тигры бродят! (с)
>которые продаются потому

Нет. Они продаются потому, что купив 100mbps пользователь использует реально средневзвешенные 5 мегабит. Итого, имея 100 мегабит в аплинке мы можем продать их 20 раз.

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

А подумать?

Платные услуги, дополнения, плюшечки и фишечки, продажа трафика (не сеошникам, а ISP, если проект крупный), оффлайн-товары, мероприятия… список грозит стать бесконечным.
А чего один мегабит? -)

У нас и больше можно, если знать, где и как.

Вы бы нам в Екатеринбурге сделали WiMax и решили проблему тысяч айтишников с ноутбуками, вроде меня. :)
Им это мало поможет — Google пока вполне решает свои задачи.

Я вообще воспринимаю подобные вещи как свистоперделки. Может потому, что так и не смог привыкнуть к засовыванию всего, чего только можно в среду. Пусть каждая софтина решает свою задачу, т.е. файловый манагер останется файловым манагером, а не RSS-аггрегатором и веб-браузером.
Поддерживаю. Дико бесит, когда парсер вырезает куски блоков кода. Например, директивы конфигурационных файлов или [x] отметки.
Ну а под Оперу? -(
Даже если сервер не отзовут совсем, с серыми клиентами он будет улетать в блэклисты, списки, спамбазы и т.д.

На сами «черные» сайты частенько идут ДДоСы, флуды, зачастую появляются дырки в написанных быдлокодером (нормальные такое редко пишут) скриптах…

А это доступности и надежности не добавляет.
Эту проблему решают тикетницы. Где можно выгрузить все диалоги саппорта за время\по сотруднику. В некоторых есть возможность оценки ответа клиентом.

А вот телефон\ICQ контролировать практически невозможно.
Это явно не хостинговая задача. А если коло\дедик — то в зависимости от трафика нужен или выделенный канал или соотношения.

Россия, зарубеж? «Там» проще и дешевле купить хороший канал, но надо быть готовым к общению по серьезным вопросам (та же отдача от трафика) на английском языке. «Тут» проще договориться о специальных условиях по трафику\размещению при больших объемах или иной мотивации для ДЦ.

А вообще — все просто. Звоните в ДЦ, просите старшего менеджера\руководителя, обсуждаете. :) С саппортом или младшими сейлз, такие вопросы обсуждать бесполезно — в большинстве компаний у них банально нет на это полномочий.
Вот и появились люди, которые не знают про «ни единого разрыва». :)

Гугл подскажет… и даже покажет.
Корпоративный блог должен вести директор\ведущий разработчик\технолог или подобный специалист, который может писать _интересно_. И писать туда надо именно интересные вещи — бизнес-процесс, технологии, мысли и т.д.

Блог, который заполняет секретарша из коллцентра когда нечем заняться никому не нужен и никому не интересен. Аналогично интересны единицам «пресс-релизы» из двух строк, «новости» полугодовой давности и пеар самих себя.
Отказ отражать ддосы на виртуальном хостинге — вполне нормально. Там не вы одни, и от атаки будут страдать другие клиенты.

Отказ манибэка не просто не нормален, но и противозаконен (Не знаю, как на Украине, но в России — если услуга не оказана или оказана не полностью — платить не за что).
Пытаться рекламировать IT-услуги спамом — вернейший путь загнать проект в могилу.
Это настолько же верное утверждение как и «все сантехники — алкоголики», «все таксисты — обманывают» и прочие профессиональные заблуждения.

Есть хорошие, есть плохие. Как везде.

По поводу сайтов. Их не должны бояться. Они не для этого делаются, это не «профсоюз клиентов хостинга» и не юридическая поддержка кинутых клиентов. А вот зайти туда перед выбором оператора — можно и нужно. Почитать, что о нем другие клиенты пишут… Про многих все становится ясно и понятно. :)
Советую проверить права на файл, в каком режиме и с какой кодировкой файл сохранен и т.д.

Очень похоже или на проблему в перечисленном выше, или глюки apache+php-cgi.
>работает ровно 5 минут

php.max.exection.time, ИМХО.

А выдавало оно скорее всего что то вроде «Header already sent».
>Я бы наверное еще добавил то, что всевозможные ограничения на сайты, базы, пространство и прочие мелочи растут именно из ограничений ресрусов CPU/MEM/Uplink, а не из жажды наживы.

В идеальной ситуации — да. В реальной, к сожалению, нет. Зачастую эти параметры используются как «завлекалово», аля «у нас везде анлим».

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Works in
Registered
Activity

Specialization

Specialist
From 1,000,000 ₽