Культура программирования биллинга тоже на уровне PHP?
На этом форуме сидят десятки админов. Каждый из них насмотрелся на PHP. Каждый из них за свой опыт работы понял, что если код написан на PHP, то он написан очень плохо. Не потому, что PHP плохой язык. А потому что он слишком легкий, что бы стать первым и при этом в отличии от Python, например, не навязывает культуру программирования.
Если человек вошел в мир программирования через PHP, на нем можно сразу ставить крест. Если он вошел через другой язык, то он не станет писать серьезное приложение на PHP.
Да там кто-то холиварить и оффтопить начал, а я поддержал. На самом деле в мире хостинга мелкомягким делать нечего. Для этого продуктам MS нужно сначала TCO понизить.
Ну делайте CCR. Вот Вам нет единой точки. Там как хочешь вертеть можно.
Чото на какой-то дешевый холивар скатились :D.
Выбить из голов линуксойдов, что MS далеко не дерьмо также тяжело, как выбить из голов приверженцев мелкомягких, что Linux это что-то инопланетное. И то и другое полный бред.
На каждую задачу своя платформа. Все эти платформы могут многое. Гавно давно уже вылетело с рынка. Те кто остались - хорошие.
Hub-transport например. Там связи все-ко-всем. Пока хоть один hub жив, система функционирует как ничего не случилось. Причем если вообще все hub-ы сдохли, то командование на себя принимает любя из остальных ролей, кроме EDGE (потому что она за пределами AD и имеет одностороннюю связь с кластером). Это сложнейший кластер. Просто нереально сложный и огромный.
Так, для затравочки: это только раутинг
А как вам SMTP-кластер?
Zimbra, Communigate и Oracle CMES тут просто рядом не стояли. А ведь это всего лишь почтовик :D
мелкомягкие не зря свой хлеб кушают. Есть сферы, где они лучшие и по сути не достижимы. Как минимум это в кластерах.
Sanbolic+Hyper-V. И да, виртуальная машина может быть больше физической ;)
Поддерживаю. Какой кластер у MS на Exchange, до такого nix'ы дойдут лет через 20 минимум.
Все-таки я прочитал текст на картинках. Сделал следующий вывод - столкнулся неграмотный клиент и быдло в саппорте. Если не пингуется VPS, а после рестарта пингуется, значит проблема программная и делать ее должен клиент (я верно понимаю, что администрирование сервера либо платное либо производится клиентом?).
С другой стороны, конечно, если саппорт употребляет слово "офигеваю", то это до свидания такой саппорт.
Ок, тогда вопрос. Почему во всех картинках filemgr?
Это не вопрос доказывающий, мою правоту. Тем более я не могу понять, на какую тему вы со мной спорите. Это просто вопрос, на который никто из вас отетить не может. А факт на лице: filemgr во всех 100% случаев паники ядра.
Ядро с патчем от мейнтейнеров конкретного дистрибутива не называется ванильным. А ядро, скачанное с kernel.org ванильное. Впрочем я не настаиваю на терминологии. Главное, что ядро с kernel.org, а патч с BlueHost, только переделанный нашим инженером.
Я не назову ни одного хостинга, самого именитого, у которого в теме на серче нету слова "тормозит" (кроме сетевых причин на уровне датацентра). И это факт. Только тема не этому посвящена.
Если Вы помните, что на картинке, то там именно это приложение сбивалось. Никакое другое. Просто так этот баг не вылезет. Видимо переменная all_path тоже была "не такая".
В общем то, я конечно не прав, так назвав тему, но кнопки переименования к сожалению нет. Погорячился. Хотя столько уже натерпелся от ISP, что это нормально, что она первый подозреваемый )))) Может оно и заслуженно. Даже если здесь вина и косвенная, то все равно ISP - притча во языцах. И никуда с нее не слезть, раз уж начали на ней. Слишком глубоко ушли.
Ну так а патч на ядро.
Да. Неаккуратная работа с указателями в C++ вызовет панику ядра. В Java так накосячить не получится. Только если специально и то тяжело. C++ крайне гибкая штука, но если не уметь им пользоваться, то он в мясорубку сервер превратить может.
Данная проблема, как выяснилось была именно в кривом коде C++. Как видите свалил сервер.
Вот мой коллега нашел строчку:
strncat(all_path, "/", sizeof("/"));
Объединили два стринга. Только длина второго была не количество символов, а количество байт, которое занимает "/", а это больше. Образовался пустой участок памяти, который вышел за обозначенные пределы и вот Вам пожалуйста, kernel panic вызванный кодом C++.
Ну так то да, но ядра не kernel.org )))) С Кернела скачали хорошее ядро, а испортили его уже потом. Нечего им багрепортить. Самим исправлять надо.
Открытым остался только вопрос, почему именно ISP попался на это.
Ну, например, попробуйте поиграться с указателями памяти в Java. Не уверен, что у Вас что-то получится. А эти положить сервер элементарно. В C++ можно руками их задавать.
Это не баг ядра. Это баг бэкапной системы, частично внедренной в ядро.
