Да, товарищи, SpaceWeb давно стал портиться, уже не первое обращение в поддержку заканчивалось ничем. Но теперь вынужден констатировать что похоже ему пришел полный капец: Кидают партнеров, и напрямубю отказываются исправлять явные ошибки.

Ну да давайте подробнее.

Кидок партнеров фирмой SpaceWeb

Я многим советовал этот хостинг, многих партнеров привел, и всем предоставлял честно обещанную помощь и консультации. Надеюсь некому меня упрекнуть в чем-либо. Полагаю что я не был самым активным партнёром, но и не двух человек привел им. На текущий момент у меня значится 27 прямых активных клиентов (было за 30) и 61 второго уровня. И до недавнего времени все было более-менее в порядке - партнерство, честное сотрудничество, выплаты хоть и задерживались, но в общем всегда совершались. На сколько я понимаю, теперь они решили что им привели не мало клиентов, и делиться обещанным с теми кто это сделал уже нету большого смысла,решив организовать банальный "кидок". Т.к. полагаю долго это не провисит у них на сайте, лучше процитирую с той ссылки:

Завершение вебмастерской программы SpaceWeb и партнерские выплаты

26.11.2010

Уважаемый партнер!

6 декабря 2010 года текущая партнерская программа для Вебмастеров завершается. 

Все средства, накопленные к 6 декабря 2010 года на балансе Вашего партнерского аккаунта, могут быть использованы любым из следующих способов:

• на покупку/продление услуг хостинга и доменов;
• вывод на Ваш Webmoney-кошелек;
• вывод на Ваш банковский счет.

Для получения денежных средств Вам необходимо предоставить следующие документы:

1. Договор, подписанный с Вашей стороны (договор будет доступен в Панели Вебмастера в разделе меню «Поддержка» с 6 декабря).
2. Копию первого разворота паспорта (где находится фотография и дата выдачи документа) и копию страницы с информацией о прописке.
3. Отчет на сумму, доступную на балансе к 6 декабря, подписанный с Вашей стороны (отчет будет доступен в Панели Вебмастера в разделе меню «Статистика» с 6 декабря).

Отсканированные копии вышеперечисленных подписанных документов необходимо загрузить через специальную форму в Панели Вебмастера в разделе «Личные данные». О загруженных документах мы будем оповещены автоматически. 


Заявки, отправленные до 6 декабря, аннулируются. О возможности подачи новой заявки после 6 декабря Вы будете оповещены после проверки загруженных Вами документов. 

При создании новой заявки сумма для вывода будет рассчитана за вычетом налога на доходы физических лиц. В соответствии с действующим налоговым законодательством России НДФЛ для резидентов РФ составляет 13%, для нерезидентов – 30%. НДФЛ будет направлен в налоговую инспекцию по месту Вашей прописки.

Обратите внимание, документы и заявки на вывод вознаграждения принимаются в течение 2 (двух) месяцев со дня закрытия программы. 6 февраля 2011 года партнерские аккаунты удаляются, программа полностью завершает свою работу.

Благодарим Вас за сотрудничество и желаем удачи!

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

Отказ исправлять явную ошибку

Я уже писал как они стали отказываться просто помочь, но там хоть сутуация было двоякая - могли бы, но не захотели, лень. Теперь же они просто отказываются исправлять явную ошибку! Начинают грубить и посылать на их VPS (вот кстати интересная чисто российская черта посылать пользователей на другие свои более дорогие услуги вмесмто решения проблем. Неужели после такого, если я и решу брать какой-либо сервер я остановлю свой выбор на их компании!?? Да ни в жизнь). Обратите также пожалуйста внимание, что последний ответ это когда поддержка ответила мне же сама на мою жалобу на них же в отдел контроля качества!!? Теперь понимаете как все круто "контролируется"? Привожу сразу полностью переписку дабы зря не растекаться мыслью по древу, сомневаюсь что тут можно сделать какие-либо другие выводы (выделение жирным моё).

30.11.2010 16:34, SpaceWeb support пишет:

Здравствуйте!

Сервис работает правильно и без проблем, как я написал ниже, никаких ошибок
нет

Хорошо, давайте сначала. Вы признаете что получающийся дамп, не смотря на то что в нем же указано что он должен быть в UTF8 сам фактически в CP1251?

, mysql у нас стандатный.

И что? А какой должен быть? У меня тоже "стандартный".

Все переменные mysql вы можете увидеть, выведя их в консоли или через
phpMyAdmin, это наши настройки и мы их не меняем.

Могу, я прекрасно знаю. Сделайте чтобы дамп соответствовал тому что в нем написано, а какими настройками мне все равно.

Если вас что то не устраивает в наших настройках, можете брать у нас VDS и
настроить его самостоятельно.

Да, я еще много чего могу помимо. И уж если я что-то решу брать, то поверьте, не буду у Вас спрашивать что могу. И врядли брать буду у Вас. Уж простите за грубость, отвечаю лишь.

Также судя по подписи вы не являетесь владельцем аккаунта sashaphoto  и пишите
со стороннего мейла,

Именно так. Владелец попросил меня разобраться с некоторыми проблемами, т.к. сам не обладает достаточной квалификацией в данном вопросе.

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

Спасибо за рекомендации. В службу контроля качества писать хочу. Тикет удалю.

Просим Вас оценить ответ нашего сотрудника:
http://sweb.ru/support/estimate/2010113010013792/ This e-mail address is being protected from spambots. You need JavaScript enabled to view it /?changed=2010-11-30%2016:10:54


Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Обращаясь в отдел контроля качества хочу спросить одну простую вещь: Как
меня, как клиента, могут интересовать Ваши внутренние настройки, если
предоставляемый сервис работает *не правильно*? Почему поддержка признав
ошибку отказывается ее устранить ссылаясь на неназванные настройки??

Прошу повлиять на сложившуюся ситуацию.

30.11.2010 15:46, SpaceWeb support пишет:

Здравствуйте!

К сожалению без изменения глобальных настроек это невозможно.


Просим Вас оценить ответ нашего сотрудника:
http://sweb.ru/support/estimate/2010113010013792/ This e-mail address is being protected from spambots. You need JavaScript enabled to view it /?changed=2010-11-30%2015:26:44

Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Я не знаю какие у Вас настройки, и их менять я не прошу, я прошу чтобы
создаваемый дамп соответствовал кодировке, которая указана в нем же. И
только эту ошибку прошу исправить!

30.11.2010 14:36, SpaceWeb support пишет:

Здравствуйте!

Это не ошибка, а настройки mysql, причем глобальные, мы их не меняем.
Если не устраивают настройки нашего сервера, можем предложить вам например VDS

http://sweb.ru/services/order/vds

Просим Вас оценить ответ нашего сотрудника:
http://sweb.ru/support/estimate/2010113010013792/ This e-mail address is being protected from spambots. You need JavaScript enabled to view it /?changed=2010-11-30%2014:21:37



Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Простите, то есть Вы отказываетесь исправить явную ошибку некорректного
создания дампа (указывается одна кодировка, а пишется в другой)??

30.11.2010 14:16, SpaceWeb support пишет:

Здравствуйте!

Это из-за глобальных настроек mysql , это не изменить.
Если вам нужен дамп в utf8, то вы можете как либо перекодировать его
самостоятельно.

Просим Вас оценить ответ нашего сотрудника:
http://sweb.ru/support/estimate/2010113010013792/ This e-mail address is being protected from spambots. You need JavaScript enabled to view it /?changed=2010-11-30%2013:51:24


Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Здравствуйте.

Делаю на Вашем хостинге (аккаунт sashaphoto) дамп БД, так:
mysqldump --default-character-set=utf8 -u'user' -p'password'
-h'localhost' --skip-extended-insert --complete-insert --triggers
--routines sashaphoto>     fullDB.sql

Как Вы видите, даже пытаюсь явно указать кодировку utf8, база сама тоже
в юникоде. Что интересно, в самом дампе присутствует указание что он
должен быть юникодный:
/*!40101 SET NAMES utf8 */;
, но вот сам дамп почему-то при этом в CP1251:
$ enca fullDB.sql
MS-Windows code page 1251
LF line terminators

Не могли бы Вы пояснить что происходит? Почему? И исправьте пожалуйста.

-- 
С уважением, Павел Алексеев (aka Pahan-Hubbitus). Для быстрой связи со
мной используйте джаббер. Мой JID: This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Как последняя надежда, обращаюсь в службу контроля качества. То что они отвечают точно то же самое, это тоже только российский нонсенс, ну да это также по тексту, выделю только жирным чтобы подчеркнуть некоторые моменты:

Прискорбно что отказ исправлять ошибку совпадает с позицией компании.

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

03.12.2010 16:34, Служба контроля качества пишет:

Уважаемый Павел.

Служба контроля качества принимает меры в случае ошибок в работе сотрудников.
В данной ситуации ответ сотрудника совпадает с позицией компании, то есть
неточностей в его работе нет.
За Вами остаётся право обсуждения этого вопроса на любых сторонних ресурсах.

Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Странная позиция. Позицию Вашей технической службы я услышал и от
техподдержки. Смысл было обращаться в службу контроля качества, если Вы
не разбираясь озвучили ту же самую позицию!?? "Качество" по российски?

Что Вы не готовы вынести этот вопрос на арбитраж куда-либо, не удивлён.

И есть ли смысл обращаться при появлении новых вопросов??

03.12.2010 15:43, Служба контроля качества пишет:

Прошу прощения, Павел.

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

Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Во-первых меня Павел зовут.

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

P.S. Еще раз говорю, я понял что добиться исправления ошибки от Вас не
получится, если не хотите, можете больше не отвечать попусту что это не
ошибка, а настройки.
P.P.S. Вы готовы вынести вопрос такой "настройки" и оценку её
корректности на внешний арбитраж? Ну скажем на форум, что-то вроде
http://sysadmins.ru/ , http://unixforum.org/ , http://forums.mysql.com/
(можете предложить свой авторитетный ресурс)?

03.12.2010 12:49, Служба контроля качества пишет:

Уважаемый Александр Дмитриевич.

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


Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

01.12.2010 18:54, Служба контроля качества пишет:

Уважаемый Александр Дмитриевич.

Мне искренне жаль, что данный вопрос, в силу упомянутых причин, не получилось
разрешить ни в чью пользу.

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

Впрочем я понял что Вы делать ничего не собираетесь, можем на этом
остановиться.

Мы примем на заметку сегодняшнуюю ситуацию и постараемся в будущем учесть и
Ваши претензии, и Ваши пожелания.
Ещё раз примите наши извинения, если ответы технических специалистов
показались Вам невежливыми. Это вопрос также будет взят на проработку.

Спасибо Вам за понимание и сотрудничество с нами.
В любом случае я желаю Вам успехов!

Звучит красиво. Вам тоже удачи.

Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Спасибо за ответы, Валерия.

Вынужден констатировать, что развитие хостинга SpaceWeb остановилось,
надо полагать кризис роста. Еще год на зад не помню чтобы поддержка
отказалась бы хоть раз помочь, а теперь все подряд уже несколько раз (и
старый MySQL, и "кидок" партнёров, и некорректные дампы и т.д.).

Спасибо по крайней мере за вежливые ответы, Ваши в частности. Буду со
своими партнёрами искать другой хостинг.

01.12.2010 17:57, Служба контроля качества пишет:

Уважаемый Александр Дмитриевич.

Вы понимаете что cp1251 однобайтовая кодировка (8bit), и при
перекодировании в неё из мультбайтной (utf8), часть данных просто
безвозвратно теряется, так что никакая обратная перекодировка уже не
сможет помочь?
Я бы мог понять, если бы у Вас были форсированы установки использовать
cp1251, и на попытку использовать utf8 выдавалась бы ошибка. В таком
случае это было бы настройками и спецификой, и я прекрасно понимаю что
на виртуальном хостинге под всех не подстроишься.
У Вас же имеет место быть следующая ситуация: MySQL принимает указание
что дамп должен быть в utf8, записывает в файл что это так, *но потом
молча делает его в cp1251*, так что он получается именно *некорректный*,
а не просто в другой кодировке!

Чтобы было понятнее, приведу аналогию: Если на цистерне написано что она
под молоко, и когда Вы хотите залить туда бензин вам говорят что этого
делать нельзя, это одно (это настройки, форсирование использования). А
когда Вам привозят цисцерну с молоком, на ней и в документах написано
что это молоко, а там фекалии, это извините, совершенно другое (это уже
либо ошибка, либо чей-то злой умысел).

Да, мы понимаем Вас, но все возможные варианты, которые мы можем предложить со
своей стороны, мы Вам озвучили. Единственный вариант, который не упоминался
ранее, рекомендованный техническими специалистами - поставить локально какое
либо программное обеспечение для выполнения дампа БД. Мы открываем доступ к
нужной базе данных с Вашего внешнего IP-адреса. Вы выполняете дамп базы данных
своим ПО в нужной Вам кодировке.
К сожалению иных вариантов мы со своей стороны в данной ситуации предложить
просто не можем.

И пожалуйста, не могли бы Вы представится, кто отвечает?

Да, разумеется. Подпись содержится внизу письма.


Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Здравствуйте.
Благодарю хотя бы за нормальный тон ответа, в отличии от поддержки.
Далее отвечу по тексту.

01.12.2010 14:29, Служба контроля качества пишет:

Добрый день, уважаемый Александр Дмитриевич.

Мы проконсультировались по Вашему вопросу с техническими специалистами и
относительно Вашей ситуации можем сказать следующее:
действительно на наших серверах виртуального хостинга есть такая специфика
работы программы mysqldump. Эта задача, оставаясь при этом на виртуальном
хостинге, решается путём последующей самостоятельной перекодировки полученного
файла.
В общем случае перед импортом дампа БД достаточно указать корректную
кодировку (соответствующую кодировке, в которой хранятся данные на кириллице)
в запросе set names. В нашем случае set names cp1251;

Вы понимаете что cp1251 однобайтовая кодировка (8bit), и при
перекодировании в неё из мультбайтной (utf8), часть данных просто
безвозвратно теряется, так что никакая обратная перекодировка уже не
сможет помочь?

Как Вам уже и упоминали наши специалисты технической службы, это не ошибка,
это именно специфика, изменение которой на настоящий момент не представляется
возможным.

Я бы мог понять, если бы у Вас были форсированы установки использовать
cp1251, и на попытку использовать utf8 выдавалась бы ошибка. В таком
случае это было бы настройками и спецификой, и я прекрасно понимаю что
на виртуальном хостинге под всех не подстроишься.
У Вас же имеет место быть следующая ситуация: MySQL принимает указание
что дамп должен быть в utf8, записывает в файл что это так, *но потом
молча делает его в cp1251*, так что он получается именно *некорректный*,
а не просто в другой кодировке!

Чтобы было понятнее, приведу аналогию: Если на цистерне написано что она
под молоко, и когда Вы хотите залить туда бензин вам говорят что этого
делать нельзя, это одно (это настройки, форсирование использования). А
когда Вам привозят цисцерну с молоком, на ней и в документах написано
что это молоко, а там фекалии, это извините, совершенно другое (это уже
либо ошибка, либо чей-то злой умысел).

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

И пожалуйста, не могли бы Вы представится, кто отвечает?

Pahan-Hubbitus < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > написал(а):

Обращаясь в отдел контроля качества хочу спросить одну простую вещь: Как
меня, как клиента, могут интересовать Ваши внутренние настройки, если
предоставляемый сервис работает *не правильно*? Почему поддержка признав
ошибку отказывается ее устранить ссылаясь на неназванные настройки??

Работа с разными кодировками и сравнениями (collations) вполне себе
штатная функция MySQL с очень давних времён.
Почему мне все время указывают на то что я должен купить ВДС, вместо
того чтобы исправить проблему? При чем здесь системные настройки,
которых я ни разу менять не просил?

Прошу повлиять на сложившуюся ситуацию.

Вот так-то вот товарищи. Понимаю что получилось очень длинно, потому без особых комментариев.

Выводы

Ну а какие могут быть еще выводы? Кратко я их озвучил уже в письме - видимо у компании кризис роста. Помнится то же самое было и с Инфобоксом (Infobox.ru) - сначала начали стирать темы на форуме, потом замалчивать о проблемах, перестали их исправлять и идти на помощь пользователям, потом перевели партнерку на "официальную" в одностороннем порядке уменьшив выплаты, и чуть позже вообще всех кинули подобным образом. Начинал я об этом писать тут, но подробнее так и не хватило сил и пороху. Похоже, к сожалению, что это "эталон" российского бизнеса.

Я уже сколько могу стараюсь не пользоваться услугами российских компаний когда это возможно, чего и всем желаю: основные домены регистрирую в Namecheap, мой личный хостинг располагается в Америке вот уже несколько лет - Hostgator, сервер арендуем (для проекта stroydostavka.com) у ангичан в компании Poundhost (и для следующего проекта планирую пока брать там же).

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

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