> Краткий диагноз по диагонали половины субтреда: > Алексей, Вы боитесь того, что даже не попробовали пощупать. > В данном случае совершенно напрасно.
В определенных ситуациях использование виртуального сервера оправдано, я это в каждом сообщении говорил. Но вопрос остается в силе - когда виртуализация _не может быть_ использована? Например, для перегруженного сервера (с какими параметрами?), еще в каких-то случаях. Где граница применимости? > > > Веб-сервера, включая пресловутый апач (если им еще кто-то > > пользуется) тоже виртуальный хостинг поддерживают. > Это не тот "виртуальный". Примерно как сказать, что "X Windows > -- среда для работы приложений Windows" [хотя есть rdesktop, vnc > и wine ;]. Несколько сайтов на одном ip. Вроде как было придумано для экономии ресурсов (в данном случае ip-адресов). Идея та же самая. На один физический сервер зарегистрировано много сайтов, стоит себе одна железка, на ней один апач и т.п. > > > И т.д. Не исключаю, что может возникнуть необходимость > > в виртуализации ОС, но не у всех и не всегда. > > Речь пошла не о виртуальном железе. А о виртуальных контекстах. > Это гораздо легче и удобнее. Практично бывает тогда, когда > по-хорошему задачу бы надо вынести на отдельный тазик, но его > либо никто не даст, либо некуда поставить. > > Пример "на пальцах" -- думаю, я подниму apache1+mod_perl+mod_php4 > и, скажем, apache2+mod_php5 на одном тазу, вот только осмысленно > будет разнести их в два, а то и в три разных VE. И всем будет > только лучше, как правило. Возможно. Вопрос: есть N подключений к апачу 1, и M к апачу 2. Насколько уменьшатся допустимые Nmax и Mmax после виртуализации? > > Могу разве что предложить поиграться на досуге с тем же ovz, > vserver, мож ещё чем вроде xen/qemu/virtualbox/vmware, чтоб > по крайней мере не дезинформировать людей о том, что где полезно > и работает, а что куда совать смысла нет. По ovz мне тесты подсказали, уже есть что тестировать. Попробую. > <провокация> > И при этом используете Debian, а не ALT или Owl? Хех. > </провокация> Дебиан - понятно, а остальное, наверное, для тех, у кого нет дебиана :-) > Админу писать свой -- заведомо хуже. Даже компетентному > разработчику, как правило, полезней поискать хорошую открытую > базу и отталкиваться от неё, возвращая свои наработки для общей > пользы, чем городить своё. Исключение мне известно одно: когда > мера безопасности "шоб никто не догадался" такой ценой считается > оправданной. В определенных областях хороших наработок не удается найти, потому и пишется свое. Тут уже вопрос стоит, как интегрировать с существующими наработками, чтоб меньше писать "с нуля". И в первую очередь имеет смысл выбрать, с чем стоит работать, а что лучше реализовать самому или поискать другую реализацию. > Если бы из этого поделия не было так часто можно выбраться... > Да и узнать о том, сколько оно может попытаться глотнуть > виртуальной (sic:) памяти при каком-нить -Xmx 256m -- тоже > отдельный прикол. > > > Получается, бардак растет на всех уровнях > > Вам явно противопоказано пользоваться протоколами на основе > TCP/IP с таким обострённым чувством прекрасного... :) Скажем так, я пытаюсь понять, как "хотели лучше" разработчики и что у них потом получилось. И тоже стараюсь делать как лучше, а не ориентироваться на "как всегда". Администрирование и разработку разделить стало очень сложно (очень много готовых решений всех мастей), потому много вопросов появляется именно по вопросам администрирования. > > И, как я вижу, навык поставить виртуальную машину и запустить > > быдлокод в ней все увереннее заменяет собой умение писать > > грамотный код. > > Можно поинтересоваться списком Ваших проектов и тем, > как оценивали качество хотя бы просто кода? Крупных решений немного - а точнее, всего два, система мерчендайзинга и документоборот. Плюс некоторые вычислительные - восстановление трехмерного рельефа дна, создание дифракционных линз, еще кое-что. Оценивал по наличию единого читаемого стиля кода и использованным алгоритмам. Согласен, что код форума нет необходимости оптимизировать, как, скажем, быстрое преобразование Фурье, но, к примеру, десятки раз вычислять одно значение или сто раз стучаться к БД вместо написания и вызова хранимой процедуры для меня достаточно, чтобы больше не вспоминать о таком ПО. > > Про форумы всё понятно, вот только плеваться проще, чем хотя бы > отобрать "хорошие" и советовать людям, когда спрашивают. В рассылке периодически пробегают обсуждения в том числе и форумов. И часть из них вполне удовлетворяют достаточно строгим требованиям, так что выбирать есть из чего. > > >P.S. Вы, кажется, предлагаете платную поддержку debian? > > А мы -- платную поддержку ALT Linux. > +1, и это ни разу не "ода быдлу". Заказчик может хотеть немного > странного и при этом в общем и в целом быть нормальным, вменяемым > и стоящим дела. Идеальных (по концу работы, не по ТЗ и началу) > мне ещё не встречалось. Если вы работаете с заказчиком с момента составления ТЗ, вполне возможно сообщить, что определенные технологии и продукты безопаснее других и привести примеры. К разумным аргументам большинство заказчиков прислушивается. Другое дело, что собрать эти разумные аргументы сложно. Как видите, очень часто на мои вопросы отвечают "это хорошая и нужная технология, потому что я ее использую". И только 1 (!) человек прислал результаты тестов, по которым в самом деле можно составить мнение.
