Современный мир информационных технологий немыслим без Виртуализации "всего на свете" - серверов, операционных систем(ОС), сетевых плат(NIC-карт)-(Xsigo), дисковых массивов(NAS,RAID)-(HDS - Hitachi Data Systems).
Однако, мало кто задумывается над тем, что именно привнесла виртуализация в современный IT, и в чём на самом деле её недостатки, а где именно - достоинства.

Начать можно с того, что оказывается было нужно, чтобы появился термин паравиртуализация, который ничего специфического не означает, а лишь описывает некоторую подгруппу виртуализации, в которой исходный код гостевых ОС(тех, которые виртуализируются) был изменен таким образом, чтобы по предоставленному API(законченному набору функций) она могла обращаться к главной ОС(так называемой Хостовой) машине в случае наиболее неотложных операций(выделение памяти, страничный обмен, прерывания от внешних устройств, специфические функции отдельных приложений, требующие максимум hardware-ресурсов за короткий промежуток времени).
Паравиртуализация понадобилась неспроста, так как общеизвестно, что любая программа выполняется в виртуальной машине заведомо медленнее, чем на реальной физической hardware машине(сервере). Происходит это потому, что в виртуальной среде имеется дополнительный "слой", через который гостевая машина обращается к хостовой для выпонения любых операций и невозможно каким-либо образом исключить этот "избыточный" слой задержки. Так вот, придумали, что в случае таких "критических" операций на гостевой ОС - они (операции) передаются по прерыванию в главную хостовую машину и выполняются там, что позволяет значительно ускорить гостевую ОС.

Кроме того, широко обсуждается "мобильность" целой гостевой ОС, то есть возможность миграции(или переноса) по локальной или глобальной сети целой виртуальной машины(или аналога физического сервера), представленной в случае виртуализации в виде всего одного файла .VMDK, правда размером более чем несколько гигабайт. А что именно даёт такая мобильность?
Кроме достоинств, связанных с DR(Disaster Recovery-восстановление после пожара,стихийного бедствия) и BackUp(восстановление на случай кратковременного сбоя), сопряжена такая мобильность и с риском потери именно той актуальной копии данных, которая может понадобиться в любой момент. Другими словами, можно запутаться где именно что - поскольку копий виртуального сервера стало более одной, неизвестно в чём отличие одной от другой, и где наиболее "свежая". Тот, кто хоть немного имел дело с виртуальными машинами и их "резервным копированием" - поймет, как это легко - запутаться в их множестве и/или актуальности на определенный момент в прошлом или будущем.

Вдобавок, существует целый класс серверных приложений, которые нуждаются в Кластеризации. Например, Oracle Grid - кластер из нескольких физических серверов для "распараллеливания" нагрузки на базу данных с одного - на несколько физических серверов.
Не приходится говорить, что не любую ОС возможно паравиртуализировать из-за закрытости кода например, и не все приложения нуждаются в виртуализации, есть такие, которые скорее наоборот хотят "больше есть hardware", чем быть виртуализированными.

Вообще, сложилось у меня впечатление, что виртуализация может быть оправдана(или обусловлена) лишь наличием legacy-hardware(унаследованное железо) и inherited-software(доставшийся в наследство софт). Причем, серверное программное обеспечение, как правило, менее нуждается в виртуализации, в сравнении с настольным ПО, так как оно легко комбинируется в виде NT-сервиса или Unix-процесса (устанавливается с другими приложениями на одном и том же физическом сервере). Зачем же тогда его виртуализировать, заранее предполагая потерю его производительности, связанную с выполнением в виртуальным домене, в котором всё эмулируется - память, процессор, жёсткий диск, сетевая плата?
Однако, мало кто задумывается над тем, что именно привнесла виртуализация в современный IT, и в чём на самом деле её недостатки, а где именно - достоинства.

Начать можно с того, что оказывается было нужно, чтобы появился термин паравиртуализация, который ничего специфического не означает, а лишь описывает некоторую подгруппу виртуализации, в которой исходный код гостевых ОС(тех, которые виртуализируются) был изменен таким образом, чтобы по предоставленному API(законченному набору функций) она могла обращаться к главной ОС(так называемой Хостовой) машине в случае наиболее неотложных операций(выделение памяти, страничный обмен, прерывания от внешних устройств, специфические функции отдельных приложений, требующие максимум hardware-ресурсов за короткий промежуток времени).
Паравиртуализация понадобилась неспроста, так как общеизвестно, что любая программа выполняется в виртуальной машине заведомо медленнее, чем на реальной физической hardware машине(сервере). Происходит это потому, что в виртуальной среде имеется дополнительный "слой", через который гостевая машина обращается к хостовой для выпонения любых операций и невозможно каким-либо образом исключить этот "избыточный" слой задержки. Так вот, придумали, что в случае таких "критических" операций на гостевой ОС - они (операции) передаются по прерыванию в главную хостовую машину и выполняются там, что позволяет значительно ускорить гостевую ОС.

Кроме того, широко обсуждается "мобильность" целой гостевой ОС, то есть возможность миграции(или переноса) по локальной или глобальной сети целой виртуальной машины(или аналога физического сервера), представленной в случае виртуализации в виде всего одного файла .VMDK, правда размером более чем несколько гигабайт. А что именно даёт такая мобильность?
Кроме достоинств, связанных с DR(Disaster Recovery-восстановление после пожара,стихийного бедствия) и BackUp(восстановление на случай кратковременного сбоя), сопряжена такая мобильность и с риском потери именно той актуальной копии данных, которая может понадобиться в любой момент. Другими словами, можно запутаться где именно что - поскольку копий виртуального сервера стало более одной, неизвестно в чём отличие одной от другой, и где наиболее "свежая". Тот, кто хоть немного имел дело с виртуальными машинами и их "резервным копированием" - поймет, как это легко - запутаться в их множестве и/или актуальности на определенный момент в прошлом или будущем.

Вдобавок, существует целый класс серверных приложений, которые нуждаются в Кластеризации. Например, Oracle Grid - кластер из нескольких физических серверов для "распараллеливания" нагрузки на базу данных с одного - на несколько физических серверов.
Не приходится говорить, что не любую ОС возможно паравиртуализировать из-за закрытости кода например, и не все приложения нуждаются в виртуализации, есть такие, которые скорее наоборот хотят "больше есть hardware", чем быть виртуализированными.

Вообще, сложилось у меня впечатление, что виртуализация может быть оправдана(или обусловлена) лишь наличием legacy-hardware(унаследованное железо) и inherited-software(доставшийся в наследство софт). Причем, серверное программное обеспечение, как правило, менее нуждается в виртуализации, в сравнении с настольным ПО, так как оно легко комбинируется в виде NT-сервиса или Unix-процесса (устанавливается с другими приложениями на одном и том же физическом сервере). Зачем же тогда его виртуализировать, заранее предполагая потерю его производительности, связанную с выполнением в виртуальным домене, в котором всё эмулируется - память, процессор, жёсткий диск, сетевая плата?
no subject
Date: 2014-01-31 04:07 pm (UTC)no subject
Date: 2014-01-31 04:23 pm (UTC)***
Меня ещё вот такой вопрос занимает: как это столько лет обходились без виртуализации, а потом в одночасье вдруг стали абстрагироваться от физического железа? Неужели software без конкретного hardware имеет право на существование?
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-01-31 04:10 pm (UTC)Виртуальные веб-сервера у провайдеров - наглядный, но не единственный пример, когда это нужно.
no subject
Date: 2014-01-31 04:26 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-01-31 04:18 pm (UTC)Если виртуализация грамотная, то потери заметны не будут. В некоторых случаях будет даже плюс.
Но в целом да -- простая экономия железа (и нервов при восстановлении)
no subject
Date: 2014-01-31 04:21 pm (UTC)Любые ли серверные или клиентские приложения одинаково приемлемы для виртуализации?
(no subject)
From:(no subject)
From:no subject
Date: 2014-01-31 04:27 pm (UTC)no subject
Date: 2014-01-31 04:32 pm (UTC)Сформулируйте - что такое по вашему Облако/Облачные вычисления и как они связаны с виртуализацией?
(no subject)
From:no subject
Date: 2014-01-31 04:36 pm (UTC)Некоторые ОС предоставляют механизмы легковесной изоляции (jail в FreeBSD, LXC в Linux), однако их можно использовать для только если клиентов устраивает невозможность установки своих версий ядра. Таким образом, средства легковесной изоляции jail и LXC создают технологическую основу для дешёвого VPS, а гипервизоры VMwareESX/Xen/KVM/bhyve - для дорогого.
Если вы "толстый" пользователь - сразу берите себе дедик, а лучше - несколько. VPS - это игрушки для бедных.
no subject
Date: 2014-01-31 04:52 pm (UTC)В результате имеется гарантированная безопастность как для клиентских приватных данных(куки, логины,пароли), так и для сетевой среды, куда не проинкают "возможные подцепленные трояны", которые клиент мог нацеплять во время своего серфинга по сайтам?
no subject
Date: 2014-01-31 04:41 pm (UTC)А вообще удобно, если говорить о специфических серверах. Иногда действительно достаточно одного процессора, а платы расширения не нужны. Покупать на каждый сервер свою машину? Потом покупать резевную? Вот с виртуализацией на том получится сэкономить. Востановление же на момент выхода из строя является отдельной темой.
Конечно, было бы прекрасно, если бы удалось создать сервер с большим числом процессоров. Тогда стали бы обыденной реальностью тонкие клиенты. На тех же ARM-процессорах. В офисах тишь да гладь. :) Обслуживать удобно. :) Процессоры добавлять. :))
no subject
Date: 2014-01-31 05:16 pm (UTC)Зачем это нужно? Чаще всего для удобного создания отдельных независимых, свободно переносимых, экземпляров серверов. Это позволяет довольно легко решить задачу обеспечения отказоустойчивости, задачу масштабирования, задачу добавления новых видов серверов.
Чаще всего коммерческому сервису выгоднее потерять 10-15% производительности в случае виртуальных серверов, чем решать эти задачи созданием новых физических серверов по необходимости.
Как ни странно, кластеризация не противоположна виртуализации, а ортогональна ей. Но сами по себе кластеры нужны в довольно специфичных случаях, поэтому создать гомогенную среду, удобную для кластеризации, не сложно.
Скажем, облака обычно представляют из себя себя сервера виртуализации поверх кластера. Кластеризация позволяет управлять облаков как единой структурой, а виртуализация дает создавать специфические сервера в гомогенной структуре.
no subject
Date: 2014-01-31 05:40 pm (UTC)1. Более рациональное использование оборудования. Как правило, большинство серверов недогружены, т.к. берутся с запасом мощностей. Если мы вместо десятка мелких серверов берем один мощный получакм существенную выгоду не только по цене железки, но и по месту в стойке, энергопотреблению и.т.д. При подходе мощностей железки к пределу - покупаем еще одну и переносим туда часто серверов. Операция простая как 3 копейки. Нужен новый сервер - вместо закупки новой железки ( это время, деньги, место в стойке, порты коммутатора, дополнительные затраты на электроэнергию, дополнительная мощность UPS и генератора ) просто поднимаем виртуальную машинку.
2. Простота обновления оборудования - При наличии трех или более нормально загруженных серверов, можон без проблем останавливать любой сервер на Upgrade или просто замену, с минимальными простоями работающих сервисов. Перед остановкой физического сервера виртуалы просто переносят на соседние физические сервера. Время простоя каждой виртуальной машинки составит несколько минут.
3. Разработка сложных систем. При разработке и доработке сложных систем иногда требуется иметь тестовые версии боевых систем, сотоящие иногда из нескольких десятков серверов. Тут виртуализация просто незаменима.
no subject
Date: 2014-01-31 06:32 pm (UTC)То есть за "При подходе мощностей железки к пределу" следит некая программа-монитор, называемая гипервизор, не так ли?
А что случится если вдруг произойдет непредвиденный скачок в мощности потребляемых ресурсов, который не был заложен в "берутся с запасом мощностей" ?
(no subject)
From:(no subject)
From:no subject
Date: 2014-01-31 05:45 pm (UTC)no subject
Date: 2014-01-31 06:42 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-01-31 09:38 pm (UTC)(no subject)
From:no subject
Date: 2014-01-31 06:30 pm (UTC)При этом я бы на месте автора я бы был поаккуратнее с лидерами в тех или иных областях. Потому что я, например, плохо знаю, что такое Hitachi Data System, но вот намного лучше знаю что такое EMC Avamar. Про виртуализацию сетевых подключений я тоже промолчу.
Собственно, все что описано автором, является просто частными случаями применения разделения аппаратуры и ОС. В том числе это распределение нагрузки, возможность переноса виртуальной машины между разными датацентрами.
Да, по поводу DR. Здесь как раз виртуализация имеет лишь ограниченные преимущества. Дело в том, что для обеспечения DR средствами виртуализации необходимо виртуальную машину разнести по разным серверам, находящимся в разных датацентрах (ведь нет смысла работать в рамках одного, иначе какой это DR). Так вот эта необходимость влечет за собой необходимость иметь довольно быстрый канал связи между этими датацентрами. Причем быстрый не в терминах толщины, а времени отклика. Ну и из чистой физики-инженерии, эти датацентры должны распологаться очень близко, вроде как не дальше чем 20-30 километров друг от друга, иначе задержка репликации будет слишком большой.
В случае с бэкапом виртуализация тоже не применима. Бэкап проще делать на уровне приложений-файлов, но не образов ОС. С образами ОС невозможно делать инкрементальный бэкап, а полный бэкап занимает слишком много времени и места. Обычная политика бэкапа подразумевает полный бэкап на еженедельной либо ежемесячной основе, а ежедневно выполняется только инкрементальный.
no subject
Date: 2014-01-31 06:53 pm (UTC)Типа "если жениться то на королеве" :D
Причем быстрый не в терминах толщины, а времени отклика.
хум хау как говориться
С образами ОС невозможно делать инкрементальный бэкап
Можно
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(frozen) (no subject)
From:no subject
Date: 2014-02-01 12:12 am (UTC)1. Поддержка legacy систем. Я без особых проблем могу создать сервер хоть с NT 3.1. Удачи поставить её на современное железо.
2. Разработка программного обеспечения. Тестирование нужно проводить на целом ряде платформ. Используя виртуализацию, можно это обеспечить, не утонув при этом в количестве физического железа.
3. Поддержка snapshots (не знаю, как по-русски). Мегаудобно для предварительного тестирования обновлений и сервис паков. Вы же грамотный сисадмин, не запуливаете обновления сразу на производственный сервер? Поломалось? Откатим на предыдущий snapshot. Проблема решена.
4. Виртуальное железо не ломается. Если, например, начались неустранимые проблемы на дисковом массиве, я могу перекатить виртуальную машину на другой хост (на полном ходу!), и никто даже ничего не заметит.
5. Учёба. Хотите научиться настраивать, например Oracle. Да без проблем. Создаёте виртуальный сервер, виртуальных клиентов -- учись-не-хочу.
В-общем, если бы вы сталкивались с такими проблемами, вы бы не задавали вопроса "а зачем это надо?". Просто вы, скорее всего решаете другие задачи (может быть, у вас суперкластер для числодробилки), поэтому не видите смысла в виртуализации.
В-общем, виртуализация -- это инструмент, как, например, бензопила. Если в задачах есть "валить лес" -- она полезна. А если надо заколачивать гвозди -- бензопила действительно вам ни к чему.
А я без виртуализации как без рук.
no subject
Date: 2014-02-01 02:22 pm (UTC)А можно задать вопрос?
- Чему обязано было появление и широкое распространение виртуализации, то есть в вашем случае - бензопилы?
Уж не наличию ли множества различных ORacle, MS SQL, DB2 и иже с ними, и которые сражались между собой на предмет - кто больше производительности/масштабируемости/ресурсоэкономии выдаст, и в итоге имели более менее конкурентно-способный продукт?
Что же происходит и/или будет происходить теперь(когда - как пишет один из участников здесь - "Виртуализация - это довольно устоявшаяся технология")?
Стирается граница hardware/software и получается, что производителю не нужно завоёвывать рынок и свою нишу на нём со своим сервером БД, а только выдать некий универсальный такой продукт, который будет приемлемо работать только на кластере из полусотни физических машин, но зато умеет хорошо виртуализироваться?
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-02-01 04:52 am (UTC)no subject
Date: 2014-02-01 02:32 pm (UTC)поэтому и пост этот здесь не для профессионалов в области, точнее не для тех профессионалов, которые не в состоянии абстрагироваться от своих накопленных непосильным трудом знаний и опыта, а для таких, которые могли бы взглянуть со стороны на всё и способны оценить и выдать в перспективе - куда всё катится и к чему движется, например, лет этак через 15 каким будет софт, каким железо и что вообще будет в ИТ происходить тогда? Что останется в интернет-технологиях?
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-02-01 04:53 am (UTC)Во-первых, виртуализация - это далеко не только для виртуализации ОС. Виртуализация процессов, приложений и пользовательских сред - это тоже виртуализация.
Во-вторых, главная цель виртуализации - предоставление виртуальному объекту универсального, не зависящего от используемой аппаратной платформы HAL. Что, как ни парадоксально это будет для автора, в некоторых случаях увеличивает итоговую производительность виртуализованного программного комплекса относительно запуска его на той же аппаратной платформе - особенно это касается старых ОС с их крайним разнообразием в качестве и производительности драйверов специфического железа и отсутствием эффективных алгоритмов дискового кэширования. Известный еще со времен VmWare 3 кейс с работой виртуализованного MS SQL на определенной аппаратной платформе с производительностью 110-112% от запуска его на той же аппаратной платформе без VmWare - далеко не единственный пример (и да, для современных MS SQL и VmWare уже не срабатывает - так 97-98% в пике и добиваются).
Виртуализация позволяет изолировать серверные процессы друг от друга, обеспечив минимализацию их взаимного влияния так, что падение одного серверного приложения в core dump не приведет к отказу другого (да, в идеале это должна делать ОС, но на практике...).
В-третьих, счетная производительность является главной целью только в High-Perfomance Computing, где виртуализация и - сюрприз! - не применяется. В абсолютном большинстве других случаев есть простаивающие вычислительные ресурсы, которые могут быть использованы для обслуживания оверхеда виртуализации с минимальными потерями.
Про существенные преимущества в виде полной отвязки виртуального инстанса от аппаратного обеспечения (когда мы в общем случае можем и не знать, на каком именно сервере и СХД работает и хранится эта виртуальная машина) и, таким образом, обеспечения катастрофоустойчивости системы автор упомянул, но как-то без энтузиазма. Между тем, это один из важнейших плюсов виртуализации, снижающим TCO в разы.
Короче, виртуализация и облачные среды - это сейчас основной инструмент квалифицированного ИТ-специалиста в области серверных систем и систем хранения. Автору имеет смысл разобраться в теме глубоко, не на уровне переписки в комментариях комьюнити.
no subject
Date: 2014-02-01 06:25 am (UTC)Железо различных программно-управляемых систем (зачастую Линуховых) сейчас переросло потребности софта. При этом, производитель только и ждал этого - можно начинать уплотнять физическую ноду виртуальными, с соответствующим ростом емкости ноды. Например, в области крупной связи.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2014-02-03 05:23 am (UTC)Современность за синтетическими стеками ввода-вывода (как в Hyper-V), когда нет никакой эмуляции портов-регистров железки, а есть 1 выход в гипервизор на каждую операцию на ней. Кроме того, есть еще SR-IOV, когда умная эзернета состоит из субмодулей с выделением "гостям" целиком субмодуля.
Это убирает основную причину потерь производительности в виртуализации. Производительность гостевого page fault уже давно не проблема, меры по ее решению уже давно вшиты в процессоры.
>виртуализация может быть оправдана(или обусловлена) лишь наличием legacy-hardware(унаследованное железо) и inherited-software(доставшийся в
>наследство софт).
Виртуализация может быть (и есть) оправдана и обусловлена желанием разделить физические хосты (железные коробки) и логические хосты (единица развернутой ОС и приложений в ней), и независимо администрить те и другие активы предприятия :) Еще напомню про SANы и storage virtualization.
А потери производительности процентов в 5-10 _просто никого не волнуют_.
>так как оно легко комбинируется в виде NT-сервиса или Unix-процесса (устанавливается с другими приложениями на одном и том же физическом сервере)
Детский сад, штаны на лямках. Подвальный вебсервер для какого-нить ТСЖ так делать можно, серьезную ИТ-инфраструктуру - сложно и противно.
То, что серверное приложение требует неких настроек окружающей ОС, в голову не приходило?
А то, что разные серверные приложения имеют всякие интеропы между собой, не приходило?
В наше время _каждый новый вебсервер под Линуксом_ (а в некоторых случаях и под виндами, просто Server Core не все админить умеют, а полновесная винда с Проводником на виртуальном вебсервере - как-то тяжеловато) - это с нуля поставленная VM ради одного-единственного httpd.
А мобильность целой VM есть уже года 4 у всех вендоров. Никаких проблем с тем, где последняя копия, у нормальных людей, у которых руки откуда надо растут, не возникает. Прекрасность всего этого, например, в легкой замене железной коробки сервера на более новую (при условии, что осталась еще как минимум 1 таковая коробка) прозрачным для клиентов образом.
no subject
Date: 2014-02-03 11:45 am (UTC)Замечание: старое железо не имеет нужного функционала (процессоры не поддерживают инструкции и т.п.) для развертывания современных гипервизоров.
В настоящий момент у меня развернуты сотни виртуальных машин; для их воплощения в железе уже недостаточно физических ресурсов, а главное - это бессмысленное их (ресурсов) расходование, потому как в большинстве своем сервисы не создают значимой нагрузки и теперь могут быть разнесены на разные машины, что упрощает контроль и обслуживание.
Физ сервера требуют:
1) отдельную эл. розетку (а то и две)
2) не менее одного сетевого порта (в реальности больше, потому как teaming, RSA, BMC и прочая хрень)
3) место в стойке,
4) КВМ
5) SAN-порт (обычно, не менее двух).
Виртуалка легко и удобно мониторится снаружи, и в случае необходимости может быть вынесена на физ. сервер, что, в прочем, маловероятно.
У виртуалок есть ограничения по работе с некоторым внешними устройствами: USB, LPT и com портами. Так же наверняка найдется целый список промышленного оборудования с которым возникнут сложности, но это частный случай.
no subject
Date: 2014-02-04 03:13 pm (UTC)Планировал я здесь услышать простых и не распальцованных инженеров и просто технарей с вопросами, которым не особенно вдомек про некую виртуализацию - и с чем её едят, - поскольку сообщество не только и нестолько для ИТ-шников.
Однако, как всегда набежали злые ИТ-шники со своими "уже года 4 как", "Паравиртуализация - прошлое", "", которые я понимаю конечно чаще в браузере/интернете живут чем другие.
Потому и дискуссия несколько смигрировала из общей в частную, интересную для более узких групп, админов серверов в основном.
Ну что ж, я не в обиде, зная любимую привычку наших постсоветских людей - покритиковать ;)
Надеюсь, что кому-нибудь из неИТшников эта дискуссия была любопытна, а то и познавательна.
Даже не знаю, стоит ли продолжать в том же духе здесь, так как от инженеров общих вопросов из практической плоскости довольно мало.