Страница:
По мнению российских ученых, исследования действительно чистой реакции термоядерного синтеза следует продолжить. Есть надежда, что проблему ее эффективного поджига удастся решить, и тогда водород и бор смогут стать достойной заменой тяжелым изотопам водорода. - Г.А.
Новости подготовили
Галактион Андреев
[galaktion@computerra.ru]
Тимофей Бахвалов
[tbakhvalov@computerra.ru]
Сергей Борисов
[borisov28@yandex.ru]
Артем Захаров
[azak@computerra.ru]
Денис Зенкин
[dz@infowatch.ru]
Бёрд Киви
[kiwi@computerra.ru]
Денис Коновальчик
[dyukon@computerra.ru]
Антон Шириков
[shirickov@computerra.ru]
ПИСЬМОНОСЕЦ: О пользе правильного питания
Приз в виде книги Сергея Голубицкого «Великие аферы XX века» достаются Azat’у в качестве компенсации за мучения.
С утра все было как-то не так, но компьютер еще работал… А началось с того, что от нехватки питания умер винчестер. После трех-пяти перезагрузок наконец-то включилась мышь (питание), благо когда она загрузится, можно определить через три секунды, далее по непонятным причинам захрипел звук. После пяти reload’ов решил протереть звуковушку (SB Live 5.1). Вкл… Винчестер умер еще во время загрузки Windows XP Pro SP1. Релоад. Мышь не включилась. Релоад. Запуск ОС со старой удачной конфигурацией. Опять умер винт. Релоад… Мышь… Релоад… Загрузилось. Ага! Звук не в тот слот воткнул. Выкл. Плюнул (не помню, где родной). Снова пять релоадов (мышь). О! Windows загрузилась! И сразу простил винчестер за прерывание загрузки, и понял, что звук в другом месте, и без лишних разговоров все исправил. Вот и ругайте после этого Б. Гейтса.
ОТ РЕДАКЦИИ: Вы думаете, у нас лучше? Подходит ко мне наш корректор, говорит, что компьютер завис как-то странно, и дымом пахнет. На экране - известная синяя страничка с белым текстом, в окрестностях пахнет горелым. Нюхаем внимательно. Системный блок? Нет. Монитор? Нет. Блок питания монитора? Нет. Клавиатура? Нет. Мышь??? Да!!! Она горячая и дымится. Всё выключаем, разбираем. У мыши, понятное дело, находим прогоревшую дырку в микросхеме. Пытаемся включить без мыши - не работает. Меняем блок питания - не работает. Меняем системную плату - работает, но нет клавиатуры. Меняем клавиатуру и ставим новую мышь - работает. Ставим обратно старую системную плату - работает. Ставим обратно старый блок питания - работает. Подключаем винчестер и загружаемся - система нормально запускается. Итого, в мусорном ведре лежат мышь и клавиатура. Ну и что это, как не происки коварного Гейтса?
Здравствуйте, уважаемая редакция!
Открыв страницу «13-я комната», я начал читать занимательный текст про предложение Google для программистов «Как провести лето». Да, очень интересный и захватывающий программистский дух очерк.
Даже предисловие интересное - товарищ выпускающий редактор посыпает голову и свой письменный стол пеплом, что, мол, от выпускающих редакторов один вред, но он попытается реабилитироваться приводимым далее очерком.
Все замечательно в этом очерке, но САМОЕ главное не учел товарищ выпускающий редактор В. Гуриев. Указывая, что каждый читатель еженедельника может успеть сделать заявку до 14 июня, он не учел, что до Сибирской и Дальневосточной частей России журнал идет (путями РосПечать) от двух недель и более.
Из всего этого следует, что в роли выпускающего редактора и автора страницы «13-я комната» В. Гуриев не только не смог реабилитироваться, но и нанес тем самым моральный вред значительной части читателей.
Просьба в следующий раз зря не посыпать голову пеплом, заранее не подсчитав хотя бы сроки доставки еженедельника по стране.
ОТ РЕДАКЦИИ: Интернет в виде странички Google до читателей Сибирской и Дальневосточной частей России тоже идет от двух недель и более? Предвидя возможный ответ «вообще не идет», предположу, что тогда вообще обсуждать нечего, потому что и заявку отправить невозможно. А судя по тому, что приведенная жалоба отправлена с копией Евгению Козловскому, до отдельных читателей не только журналы и Интернет доходят с опозданием.
День добрый.
Тут многие пишут, как «Компьютерра» помогла им написать курсовой или сдать экзамен. У меня же все плохо. Информация, которая помогла бы мне в учебе, появляется на страницах журнала на несколько недель позже, чем надо. Всегда. Потому прошу выпускать журнал хотя бы на две недели раньше.
Недавно вы совершенно верно заметили, что фамилию Bullok следует читать через У. А это, кстати, совершенно очевидно и без немецких ее родителей.
Сравните с bull.
В том же номере (и в следующем) упоминается астрофизик Leonard Susskind (Сасскинд). Что-то мне подсказывает, что совсем недавно его предки именовались на немецкий манер Зюськиндами.
Перевод имен собственных - это же вообще неблагодарное занятие. Есть ведь фамилии, о которых либо ничего, либо хорошо. Голливудская актриска Sukova при переводе становится Шуковой или Зуковой. Дети же смотрят, как не стыдно… Некоторые китайские фамилии напоминают трехбуквенные российские заборы.
Если серьезно, то «Компьютерра» - единственное неспециализированное и легкодоступное издание, где можно запросто почитать статьи, написанные не журналистами, а самыми что ни на есть учеными. За это огромное спасибо!
ОТ РЕДАКЦИИ: Мы с удовольствием будем выпускать журнал на две недели раньше, если вы взамен возьмете на себя почетную обязанность уговорить всех упомянутых самых что ни на есть ученых сдавать редакции свои статьи раньше на те же две недели.
Terralab.ru: Раз, два - горе не беда!
Вы когда-нибудь пробовали работать с виртуальными компьютерами - программами, позволяющими запустить из обычной операционной системы одну или несколько «гостевых» операционных систем в виде своеобразных приложений родительской ОС? В одном окошке - Windows 95, в другом - FreeBSD, в третьем - Linux, в четвертом и вовсе какая-нибудь DOS, Minix или MenuetOS, причем все они работают «без отрыва» от Windows XP Professional, в которой это хозяйство запущено.
И не нужно возиться с загрузчиками, создавать три-четыре раздела на жестком диске, решать проблемы совместимости операционных систем с «железом» - специальное ПО сымитирует ровно ту аппаратную конфигурацию, на которой именно эта операционная система запустится и будет функционировать без лишних вопросов. Не нужно перегружаться по десять раз на дню, если настраивать почту в Linux, переносить туда почтовые аккаунты и заниматься их синхронизацией с почтовыми программами Windows совершенно не хочется, а работать со свободной операционной системой по каким-то причинам необходимо. Не нужно опасаться, что неудачно введенная команда в свежеустановленной модной ОСи, написанной на ассемблере, угробит основную установленную на компьютере систему[По известной легенде, ОС Linux родилась в тот момент, когда Линус Торвальдс, нечаянно «позвонил модемом на /dev/hda1 вместо /dev/tty1» и таким образом вывел из строя раздел, на котором размещалась его основная рабочая система Minix. Торвальдс тогда принял вызов, засел за компьютер и в конце концов превратил свой «текстовый редактор» в полноценную POSIX-совместимую операционку. Но, боюсь, желающих повторить этот подвиг среди читателей «КТ» найдется немного]. Но программные комплексы типа VMWare Workstation или Microsoft Virtual PC 2004 - это не только идеальные «полигоны» для экспериментирования и «переходники», позволяющие запускать Windows-приложения из *nix-ориентированных систем или наоборот. Область применения подобных систем гораздо шире
В самом деле: представим на минуту, что мы можем запустить на одном и том же компьютере (персоналке, рабочей станции, сервере) несколько виртуальных взаимодействующих, но непересекающихся машин. Что это нам дает?
Появляется возможность создания сложных «гибридных» систем, вбирающих в себя все преимущества разных операционных систем и наработанного для них программного обеспечения. Хотите поручить управление сетью Windows-машин основанному на Linux серверу, но вас почему-либо не устраивает пакет Samba? Желаете организовать роутер и прокси-сервер на базе *BSD-системы, но для других целей она вам совершенно не подходит? Нет проблем: создаем столько виртуальных систем, сколько нужно, и сочетаем в одном компьютере все их преимущества.
Зачем покупать отдельный сервер, требующий непростого и зачастую дорогостоящего обслуживания, когда с теми же обязанностями может неплохо справиться и десяток персоналок? Минимальная адаптация современных пиринговых сетей - и в локальной сети появляется надежное и дешевое виртуальное хранилище данных, «размазанных» и продублированных на компьютерах самых обычных пользователей. А «виртуальность» образующих эту устойчивую к повреждениям группу машин обеспечит сети надежную защиту от действий пользователей или каких-либо случайных «внешних факторов». Даже если пользовательский ПК, скажем, зависнет, будет взломан хакером, заражен вирусом или перезагружен, - на функционировании работающего на той же самой машине виртуального «сервера» это не скажется.
На сервере работает несколько десятков пользователей с довольно широкими правами и нужно обеспечивать их взаимную безопасность и совместимость? Можно тщательно оптимизировать настройки системы, добиваясь тончайшего и почти неуловимого баланса между обеспечением разнообразных (зачастую экзотических) пожеланий пользователей и ограничением их прав в пределах, гарантирующих, что программы юзера А не будут по субботам вечером «ронять» программы юзера Б. Можно поставить отдельный Windows-сервер, отдельный Linux-сервер, отдельный FreeBSD-сервер, отдельный NetBSD-сервер, отдельный сервер на Solaris или вообще два десятка серверов, по штуке на брата. Но проще и дешевле поставить один сервер, на котором выделить каждому пользователю по «независимой» машине, принципиально непересекающейся с другими.
На предприятии стоит один и только один сервер на базе процессоров Itanium, на котором работает корпоративное ПО, а программисты, за неимением лучшей тестовой платформы, отлаживают свеженаписанные программы и заплатки прямо на «живой» системе? Создадим им виртуальную копию корпоративного «сервера на Itanium», и проблема решится сама собой.
Появляется возможность создания «дешевых» резервных серверов, служащих для замены основного сервера в случае его отказа. Скажем, можно на одном сервере продублировать роутер предприятия четырьмя разными программами.
Уже хорошо, не так ли? А что, если мы добавим к сказанному возможности «ставить на паузу», «сохранять» и «загружать» состояния наших виртуальных машин?
Радикально упрощается процедура бэкапа и процедура переноса рабочего места (или сервера) с одного компьютера на другой (при переезде или замене оборудования). Сохранил - загрузил - все работает, причем с сохранением всех настроек, вплоть до любимого пользователем расположения ярлычков в такой-то папке.
Более того, появляется замечательная возможность, например, без каких-либо проблем загружать виртуальные машины (со всеми документами и настройками) прямо по локальной сети с сервера. Обычно для обеспечения «не-фиксированного рабочего места» (сел за любой компьютер и работаешь с ним, как со своим собственным) применяют разнообразные терминальные решения, обладающие здоровенным перечнем недостатков и ограничений. Загрузка виртуальных компьютеров по сети эту проблему решает.
Ну и, наконец, появляется чудесная возможность всюду носить свое рабочее место и домашний компьютер с собой. Вечером синхронизировал ноутбук с рабочим компьютером - и твое рабочее место словно «переселилось» на ноутбук. А затем, точно так же - на домашний компьютер. И не нужно никакого постоянного широкополосного защищенного подключения.
Впечатляет? На мой взгляд, направление чрезвычайно многообещающее и во многом революционное (ну не зря же им заинтересовалась даже Microsoft). А вот используется оно сегодня крайне редко и в основном энтузиастами, нежели массовыми корпоративными и частными пользователями. Первых отпугивает обилие разнообразных проблем, связанных с существующими софтверными виртуальными ПК[На запрос «VMWare» Google выдал порядка 1 290 000 ссылок, а на «VMWare problem» - 612 000 ссылок. Выводы делайте сами. Желающие могут поставить тот же эксперимент, заменив «VMWare» на «Windows XP», «Linux», «Apache», «MySQL» либо иное другое популярное ПО, и убедиться, что «проблемных» страничек в этом случае получается в несколько раз меньше (15-18%)]; вторых - высокая цена (от 130-300 до пары тысяч долларов за комплект ПО) и общая «тормознутость» и «примитивизм» получающейся на выходе системы. К сожалению, корень зла здесь кроется отнюдь не в «безруких программистах», не умеющих толком отладить свои продукты, нет. Вся загвоздка - в непомерной сложности точного и полного софтверного решения проблемы виртуализации.
Что такое современный x86-совместимый компьютер? Если кто-то скажет вам, что это довольно простая штука, - не верьте: он просто не знает о чем говорит. Примерное представление о масштабах этой, хм, технологии дает разве что техническая документация - четыре многосотстраничных тома краткой документации по архитектуре IA-32 (The IA-32 Intel Architecture Software Developer’s manual: vol. 1, 2A, 2B amp; 3) и еще два - по ее 64-битным расширениям (The Intel Extended Memory 64 Technology Software Developer’s guide, vol. 1 amp; 2). Впрочем, о последних лучше почитать в первоисточнике - пятитомном издании AMD64 Architecture Programmer’s Manual. Реализовать по этим здоровенным талмудам даже простую имитацию современного x86-процессора - огромная работа; и еще труднее - сделать такую имитацию, которая бы умела более или менее эффективно задействовать для исполнения виртуального кода ресурсы центрального процессора. Даже куда более простая и специально оптимизированная виртуальная машина Java, как известно, работает довольно медленно; надеяться же на чистую эмуляцию средствами центрального процессора чего-либо принципиально более мощного, нежели какой-нибудь ZX Spectrum на процессоре Z80, и вовсе не приходится. Поэтому все современные виртуальные компьютеры идут другим путем - не эмулируя в прямом смысле слова несколько виртуальных ПК, а запуская на одном персональном компьютере несколько операционных систем и ловко «дурача» их, с помощью разных приемов защищая от взаимного «членовредительства» и заставляя «поверить» в то, что кроме них в системе никого нет (рис. 1). Беда в том, что каких-либо приспособлений для подобного рода «надувательства» у этих «виртуализаторов» нет - им приходится выкручиваться, используя для своих целей стандартные методы (IA-32 aka 32-разрядный x86 - весьма гибкая архитектура, и во многих отношениях сделать это оказывается возможным). Однако предусмотреть все ситуации и найти ответы на все возникающие при этом вопросы - практически нереально. Разные ухищрения, на которые приходится пускаться программистам, к сожалению, являются скорее латанием дыр в ветхом днище корабля: для того чтобы кое-как, с половинным ходом доплыть до дока, такого «ремонта» хватает, а вот для длительных морских походов или бурных морей - нет.
Рассмотрим суть возникающих неприятностей на примере так называемой проблемы нулевого кольца исполнения. Кольца (rings, они же уровни приоритета - PLs, Priority Levels) - это такая хитрая система, защищающая центральный процессор от выполнения «посторонними» программами «глубоко системных» инструкций и операций, эдакий «уровень доступа» запущенной программы к системным ресурсам. В IA-32 четыре кольца, от Ring 0 до Ring 3. Чем больше номер кольца - тем меньше приоритет и тем меньше доступно работающей программе. В нулевом кольце запущенный процесс может делать все, что заблагорассудится, - ему предоставлен карт-бланш на любые операции; так что именно в этом кольце «обитает» ядро операционной системы и непосредственно взаимодействующие с оборудованием драйверы. Третье кольцо - сильно упрощенный и ограниченный мирок, в котором запущенный процесс может свободно «жить», но изменить который он не в состоянии. Здесь «живут» всяческие прикладные программы. Кольца 1 и 2 ни Windows, ни *nix-системами принципиально не используются.
В чем же проблема? Оказывается, когда мы «дурачим» виртуальную операционную систему, то не совсем понятно, в какое из колец ее следует помещать. В Ring 0, очевидно, поместить ОС нельзя - проконтролировать ее действия в этом случае не сумеет ни одна живая душа, ибо «воля» исполняющегося в этом кольце кода обсуждению или критике со стороны процессора не подлежит. Поместить операционную систему в «непривилегированные» первое, второе или третье кольца тоже нельзя: любая ОС проектируется, исходя из расчета, что выполняться она будет в нулевом кольце привилегий, а значит, отсутствия необходимого минимума маленьких, но жизненно важных для работы ее ядра инструкций не простит. Вот и приходится программистам либо заблаговременно проверять код на предмет «неблагонадежных» инструкций, ставя на их место вызовы «правильных заменителей», либо отлавливать возникающие при исполнении «неправильных» инструкций ошибки и пытаться их на лету исправлять. Легко догадаться, что реализация и того и другого выливается в большую головную боль для программистов, причем на вроде бы совершенно пустом месте. К примеру, часто «гостевую» операционную систему размещают в неиспользуемом первом кольце… но в расширенном 64-битном режиме процессор не поддерживает кольца 1 и 2, так что все соответствующие наработки «виртуализатор», естественно, отправляет в корзину. Рано или поздно количество проблем переходит в качество - и виртуальные машины становятся не только крайне сложными с программной точки зрения, но и громоздкими, медленными и ненадежными.
Так что же делать? Отказаться от надежды на массовый виртуальный ПК? Конечно, нет! Как минимум, вместо того, чтобы заниматься замысловатой оптимизацией кода для хитроумного обмана операционной системы, можно просто внести некоторые изменения собственно в ОС, видоизменив «наиболее мешающиеся» части ядра. Подобный подход называется паравиртуализацией, он активно продвигается компанией Sun и поддержан движением OpenSource… но эту красивую картинку, к сожалению, успешно портит своими «незаменимыми продуктами» великая и ужасная Microsoft, ибо адаптировать сверхпопулярное ядро Windows NT к реалиям конкретной виртуальной машины может, естественно, только его автор; но так, как делать этого софтверный гигант не собирается (слишком уж многое нужно перелопачивать в ядре), то и сам подход получается если не тупиковым, то, по крайней мере, неполноценным. Поэтому куда интереснее второй, гораздо более простой и универсальный способ - аппаратная поддержка функционирования менеджеров виртуальных компьютеров со стороны процессора, то есть технологии виртуализации. Именно так и поступила Microsoft, разработав в тесном сотрудничестве со специалистами VMWare систему, снимающую основную «головную боль» с разработчиков соответствующего ПО.
Центральная идея Intel Virtualization Technology (ранее известной под названием Vanderpool) - введение в процессор аппаратной поддержки некой специализированной программы - менеджера виртуальной машины (VMM, Virtual Machine Manager) (рис. 1). В принципе, VMM - по всем статьям обычная программа, работающая на персональном компьютере. Однако «права» у этой «обычной» программы самые невероятные, поскольку она может вмешиваться во все мало-мальски значимые события, происходящие в процессоре. То есть, если, скажем, ядро операционной системы (работающее в обычном, ничем не ограничиваемом Ring 0) вызывает инструкцию CPUID, или читает-записывает важный системный регистр CR[Что, впрочем, неудивительно - AMD сегодня отвоевывает себе «место под рыночным солнцем», а для этого ей необходимо предлагать более совершенные и интересные решения], или произошло какое-то внешнее событие, вроде прерывания - то процессор сообщает об этом VMM и… больше ничего не делает, предоставляя VMM право реагировать на возникшее событие самостоятельно. Менеджер виртуального ПК «разбирается» в происходящем, решает, как поступить (например, может, необходимо после нажатия какой-то кнопки переключить CPU на другую запущенную операционную систему), и «программно» имитирует действия центрального процессора в подобной ситуации. Причем отслеживать разные события ему приходится довольно интенсивно: «вручную» маршрутизировать обращения операционных систем к периферийным устройствам, «вручную» загружать и переключать запущенные операционные системы, «вручную» следить за виртуальной памятью запущенных операционных систем, чтобы последние нечаянно не «покалечили» друг друга, считая себя единственными претендентами на имеющиеся физические ресурсы.
Последний пример хорошо иллюстрирует суть происходящего. Как известно, современные многозадачные операционные системы активно используют механизм виртуальной памяти, когда запущенные на процессоре программы работают с «линейными» адресами, произвольным образом отображенными в реальную физическую оперативную память (или еще куда-нибудь - например, на участок жесткого диска в своп-файле или своп-разделе). С физической памятью не работает даже сама операционная система: слишком уж это неудобно - подстраиваться под особенности конкретного ПК, и слишком опасно - когда в общей куче перемешаны данные десятков и сотен запущенных программ, и только аккуратность разработчика защищает эти данные от ошибочных действий программного обеспечения. Преобразование виртуальных «линейных» адресов в физические обычно выполняет сам центральный процессор, для чего у него предусмотрена специальная таблица трансляции адресов, в которой записано, какому «линейному» адресу какой физический соответствует (или стоит пометка, что при обращении к данному участку памяти процессору следует позвать на помощь операционную систему). Хранится эта таблица не в регистрах процессора, а в оперативной памяти (в виде трех-четырехуровневого B-дерева, если вас интересуют подробности), причем таблиц может быть сколько угодно: для переключения к другому виртуальному адресному пространству в процессоре достаточно изменить один-единственный регистр CR3 (указатель на таблицу трансляции) и выполнить специальную команду сброса и очистки кэшей CPU, в которых может сохраняться старая информация о виртуальной памяти. «Простым смертным» в лице обычных программ доступ к CR3, разумеется, закрыт, и поэтому изменить «мир», в котором программы находятся, они могут только путем обращения за помощью к операционной системе. Операционной системе «проще» - она, с одной стороны, подчиняется «общим правилам», а с другой - может эти правила самостоятельно «переписывать», работая ровно в тех условиях, которые кажутся ей наиболее приемлемыми. Скажем, если ОС срочно потребуется записать что-то по физическому адресу 0x00123456, она вначале создаст в таблице трансляции своих виртуальных адресов ссылку на соответствующий участок оперативной памяти (отобразив его в то место виртуального линейного пространства ОС, которое покажется ей самым удобным) и затем обратится по свежесозданному виртуальному адресу. Для «обычного» же процесса (который, строго говоря, почти ничем не отличается от процесса ядра операционной системы) подобная «лазейка» к, скажем, «соседям» по компьютеру закрыта - ему просто-напросто не дадут увидеть собственную таблицу трансляции, выведя ее за пределы «видимости» виртуального пространства его памяти либо защитив эту область памяти от записи (здесь тоже используется та самая таблица трансляции - в ней можно указывать права доступа к виртуальным адресам). Все замечательно, все удобно, никаких проблем.
Но стоп, - скажет здесь читатель, - а что же будет, если мы запустим две операционные системы и одна из них решит отобрать для своих целей кусочек физического, а не виртуального пространства памяти другой операционной системы, отобразив его в своей таблице трансляции? В обычных условиях это фатальная ошибка, которая быстро приведет две совместно работающие операционки к краху. Но если у нас есть VMM, то ситуация в корне меняется, ибо мы теперь можем запущенную операционную систему «одурачить», перехватив соответствующее обращение и подсунув ей не настоящий CR3, а специально подготовленную «пустышку». ОС, наивно полагая, что она полностью контролирует виртуальную память компьютера, на самом деле будет всего лишь изменять никак не связанную с настоящей таблицей трансляции область оперативной памяти. А обращения к ней, используя стандартные же механизмы виртуальной памяти, будет перехватывать все тот же VMM и синхронизировать в соответствии с ними настоящую таблицу трансляции. Красиво придумано, не правда ли? Собственно виртуальной машины у нас нет, просто мы тщательно контролируем работу операционной системы и при необходимости ловко манипулируем ею.
Набор ситуаций, «прерывающих» выполнение обычных программ и приводящих к вызову VMM, довольно гибко настраивается - вовсе не обязательно, скажем, реагировать на все обращения операционных систем к компьютерным портам ввода-вывода: достаточно указать, какие порты для какой операционной системы будут «выбрасывать» ее к VMM, а какие - работать как если бы VMM не существовало в природе. Причем догадаться о том, что ОС запущена «под неусыпным контролем», практически невозможно: VMM может, например, точно таким же образом фальсифицировать обращения к CPUID (информация о процессоре и поддерживаемых им технологиях), после чего запущенная на Pentium D операционная система будет искренне полагать, что работает, скажем, на Pentium 3 и что никакой поддержки технологий виртуализации этот процессор не предоставляет.
Новости подготовили
Галактион Андреев
[galaktion@computerra.ru]
Тимофей Бахвалов
[tbakhvalov@computerra.ru]
Сергей Борисов
[borisov28@yandex.ru]
Артем Захаров
[azak@computerra.ru]
Денис Зенкин
[dz@infowatch.ru]
Бёрд Киви
[kiwi@computerra.ru]
Денис Коновальчик
[dyukon@computerra.ru]
Антон Шириков
[shirickov@computerra.ru]
ПИСЬМОНОСЕЦ: О пользе правильного питания
Приз в виде книги Сергея Голубицкого «Великие аферы XX века» достаются Azat’у в качестве компенсации за мучения.
С утра все было как-то не так, но компьютер еще работал… А началось с того, что от нехватки питания умер винчестер. После трех-пяти перезагрузок наконец-то включилась мышь (питание), благо когда она загрузится, можно определить через три секунды, далее по непонятным причинам захрипел звук. После пяти reload’ов решил протереть звуковушку (SB Live 5.1). Вкл… Винчестер умер еще во время загрузки Windows XP Pro SP1. Релоад. Мышь не включилась. Релоад. Запуск ОС со старой удачной конфигурацией. Опять умер винт. Релоад… Мышь… Релоад… Загрузилось. Ага! Звук не в тот слот воткнул. Выкл. Плюнул (не помню, где родной). Снова пять релоадов (мышь). О! Windows загрузилась! И сразу простил винчестер за прерывание загрузки, и понял, что звук в другом месте, и без лишних разговоров все исправил. Вот и ругайте после этого Б. Гейтса.
ОТ РЕДАКЦИИ: Вы думаете, у нас лучше? Подходит ко мне наш корректор, говорит, что компьютер завис как-то странно, и дымом пахнет. На экране - известная синяя страничка с белым текстом, в окрестностях пахнет горелым. Нюхаем внимательно. Системный блок? Нет. Монитор? Нет. Блок питания монитора? Нет. Клавиатура? Нет. Мышь??? Да!!! Она горячая и дымится. Всё выключаем, разбираем. У мыши, понятное дело, находим прогоревшую дырку в микросхеме. Пытаемся включить без мыши - не работает. Меняем блок питания - не работает. Меняем системную плату - работает, но нет клавиатуры. Меняем клавиатуру и ставим новую мышь - работает. Ставим обратно старую системную плату - работает. Ставим обратно старый блок питания - работает. Подключаем винчестер и загружаемся - система нормально запускается. Итого, в мусорном ведре лежат мышь и клавиатура. Ну и что это, как не происки коварного Гейтса?
Здравствуйте, уважаемая редакция!
Открыв страницу «13-я комната», я начал читать занимательный текст про предложение Google для программистов «Как провести лето». Да, очень интересный и захватывающий программистский дух очерк.
Даже предисловие интересное - товарищ выпускающий редактор посыпает голову и свой письменный стол пеплом, что, мол, от выпускающих редакторов один вред, но он попытается реабилитироваться приводимым далее очерком.
Все замечательно в этом очерке, но САМОЕ главное не учел товарищ выпускающий редактор В. Гуриев. Указывая, что каждый читатель еженедельника может успеть сделать заявку до 14 июня, он не учел, что до Сибирской и Дальневосточной частей России журнал идет (путями РосПечать) от двух недель и более.
Из всего этого следует, что в роли выпускающего редактора и автора страницы «13-я комната» В. Гуриев не только не смог реабилитироваться, но и нанес тем самым моральный вред значительной части читателей.
Просьба в следующий раз зря не посыпать голову пеплом, заранее не подсчитав хотя бы сроки доставки еженедельника по стране.
ОТ РЕДАКЦИИ: Интернет в виде странички Google до читателей Сибирской и Дальневосточной частей России тоже идет от двух недель и более? Предвидя возможный ответ «вообще не идет», предположу, что тогда вообще обсуждать нечего, потому что и заявку отправить невозможно. А судя по тому, что приведенная жалоба отправлена с копией Евгению Козловскому, до отдельных читателей не только журналы и Интернет доходят с опозданием.
День добрый.
Тут многие пишут, как «Компьютерра» помогла им написать курсовой или сдать экзамен. У меня же все плохо. Информация, которая помогла бы мне в учебе, появляется на страницах журнала на несколько недель позже, чем надо. Всегда. Потому прошу выпускать журнал хотя бы на две недели раньше.
Недавно вы совершенно верно заметили, что фамилию Bullok следует читать через У. А это, кстати, совершенно очевидно и без немецких ее родителей.
Сравните с bull.
В том же номере (и в следующем) упоминается астрофизик Leonard Susskind (Сасскинд). Что-то мне подсказывает, что совсем недавно его предки именовались на немецкий манер Зюськиндами.
Перевод имен собственных - это же вообще неблагодарное занятие. Есть ведь фамилии, о которых либо ничего, либо хорошо. Голливудская актриска Sukova при переводе становится Шуковой или Зуковой. Дети же смотрят, как не стыдно… Некоторые китайские фамилии напоминают трехбуквенные российские заборы.
Если серьезно, то «Компьютерра» - единственное неспециализированное и легкодоступное издание, где можно запросто почитать статьи, написанные не журналистами, а самыми что ни на есть учеными. За это огромное спасибо!
ОТ РЕДАКЦИИ: Мы с удовольствием будем выпускать журнал на две недели раньше, если вы взамен возьмете на себя почетную обязанность уговорить всех упомянутых самых что ни на есть ученых сдавать редакции свои статьи раньше на те же две недели.
Terralab.ru: Раз, два - горе не беда!
Вы когда-нибудь пробовали работать с виртуальными компьютерами - программами, позволяющими запустить из обычной операционной системы одну или несколько «гостевых» операционных систем в виде своеобразных приложений родительской ОС? В одном окошке - Windows 95, в другом - FreeBSD, в третьем - Linux, в четвертом и вовсе какая-нибудь DOS, Minix или MenuetOS, причем все они работают «без отрыва» от Windows XP Professional, в которой это хозяйство запущено.
И не нужно возиться с загрузчиками, создавать три-четыре раздела на жестком диске, решать проблемы совместимости операционных систем с «железом» - специальное ПО сымитирует ровно ту аппаратную конфигурацию, на которой именно эта операционная система запустится и будет функционировать без лишних вопросов. Не нужно перегружаться по десять раз на дню, если настраивать почту в Linux, переносить туда почтовые аккаунты и заниматься их синхронизацией с почтовыми программами Windows совершенно не хочется, а работать со свободной операционной системой по каким-то причинам необходимо. Не нужно опасаться, что неудачно введенная команда в свежеустановленной модной ОСи, написанной на ассемблере, угробит основную установленную на компьютере систему[По известной легенде, ОС Linux родилась в тот момент, когда Линус Торвальдс, нечаянно «позвонил модемом на /dev/hda1 вместо /dev/tty1» и таким образом вывел из строя раздел, на котором размещалась его основная рабочая система Minix. Торвальдс тогда принял вызов, засел за компьютер и в конце концов превратил свой «текстовый редактор» в полноценную POSIX-совместимую операционку. Но, боюсь, желающих повторить этот подвиг среди читателей «КТ» найдется немного]. Но программные комплексы типа VMWare Workstation или Microsoft Virtual PC 2004 - это не только идеальные «полигоны» для экспериментирования и «переходники», позволяющие запускать Windows-приложения из *nix-ориентированных систем или наоборот. Область применения подобных систем гораздо шире
Кому нужен виртуальный компьютер?
В самом деле: представим на минуту, что мы можем запустить на одном и том же компьютере (персоналке, рабочей станции, сервере) несколько виртуальных взаимодействующих, но непересекающихся машин. Что это нам дает?
Появляется возможность создания сложных «гибридных» систем, вбирающих в себя все преимущества разных операционных систем и наработанного для них программного обеспечения. Хотите поручить управление сетью Windows-машин основанному на Linux серверу, но вас почему-либо не устраивает пакет Samba? Желаете организовать роутер и прокси-сервер на базе *BSD-системы, но для других целей она вам совершенно не подходит? Нет проблем: создаем столько виртуальных систем, сколько нужно, и сочетаем в одном компьютере все их преимущества.
Зачем покупать отдельный сервер, требующий непростого и зачастую дорогостоящего обслуживания, когда с теми же обязанностями может неплохо справиться и десяток персоналок? Минимальная адаптация современных пиринговых сетей - и в локальной сети появляется надежное и дешевое виртуальное хранилище данных, «размазанных» и продублированных на компьютерах самых обычных пользователей. А «виртуальность» образующих эту устойчивую к повреждениям группу машин обеспечит сети надежную защиту от действий пользователей или каких-либо случайных «внешних факторов». Даже если пользовательский ПК, скажем, зависнет, будет взломан хакером, заражен вирусом или перезагружен, - на функционировании работающего на той же самой машине виртуального «сервера» это не скажется.
На сервере работает несколько десятков пользователей с довольно широкими правами и нужно обеспечивать их взаимную безопасность и совместимость? Можно тщательно оптимизировать настройки системы, добиваясь тончайшего и почти неуловимого баланса между обеспечением разнообразных (зачастую экзотических) пожеланий пользователей и ограничением их прав в пределах, гарантирующих, что программы юзера А не будут по субботам вечером «ронять» программы юзера Б. Можно поставить отдельный Windows-сервер, отдельный Linux-сервер, отдельный FreeBSD-сервер, отдельный NetBSD-сервер, отдельный сервер на Solaris или вообще два десятка серверов, по штуке на брата. Но проще и дешевле поставить один сервер, на котором выделить каждому пользователю по «независимой» машине, принципиально непересекающейся с другими.
На предприятии стоит один и только один сервер на базе процессоров Itanium, на котором работает корпоративное ПО, а программисты, за неимением лучшей тестовой платформы, отлаживают свеженаписанные программы и заплатки прямо на «живой» системе? Создадим им виртуальную копию корпоративного «сервера на Itanium», и проблема решится сама собой.
Появляется возможность создания «дешевых» резервных серверов, служащих для замены основного сервера в случае его отказа. Скажем, можно на одном сервере продублировать роутер предприятия четырьмя разными программами.
Уже хорошо, не так ли? А что, если мы добавим к сказанному возможности «ставить на паузу», «сохранять» и «загружать» состояния наших виртуальных машин?
Радикально упрощается процедура бэкапа и процедура переноса рабочего места (или сервера) с одного компьютера на другой (при переезде или замене оборудования). Сохранил - загрузил - все работает, причем с сохранением всех настроек, вплоть до любимого пользователем расположения ярлычков в такой-то папке.
Более того, появляется замечательная возможность, например, без каких-либо проблем загружать виртуальные машины (со всеми документами и настройками) прямо по локальной сети с сервера. Обычно для обеспечения «не-фиксированного рабочего места» (сел за любой компьютер и работаешь с ним, как со своим собственным) применяют разнообразные терминальные решения, обладающие здоровенным перечнем недостатков и ограничений. Загрузка виртуальных компьютеров по сети эту проблему решает.
Ну и, наконец, появляется чудесная возможность всюду носить свое рабочее место и домашний компьютер с собой. Вечером синхронизировал ноутбук с рабочим компьютером - и твое рабочее место словно «переселилось» на ноутбук. А затем, точно так же - на домашний компьютер. И не нужно никакого постоянного широкополосного защищенного подключения.
Впечатляет? На мой взгляд, направление чрезвычайно многообещающее и во многом революционное (ну не зря же им заинтересовалась даже Microsoft). А вот используется оно сегодня крайне редко и в основном энтузиастами, нежели массовыми корпоративными и частными пользователями. Первых отпугивает обилие разнообразных проблем, связанных с существующими софтверными виртуальными ПК[На запрос «VMWare» Google выдал порядка 1 290 000 ссылок, а на «VMWare problem» - 612 000 ссылок. Выводы делайте сами. Желающие могут поставить тот же эксперимент, заменив «VMWare» на «Windows XP», «Linux», «Apache», «MySQL» либо иное другое популярное ПО, и убедиться, что «проблемных» страничек в этом случае получается в несколько раз меньше (15-18%)]; вторых - высокая цена (от 130-300 до пары тысяч долларов за комплект ПО) и общая «тормознутость» и «примитивизм» получающейся на выходе системы. К сожалению, корень зла здесь кроется отнюдь не в «безруких программистах», не умеющих толком отладить свои продукты, нет. Вся загвоздка - в непомерной сложности точного и полного софтверного решения проблемы виртуализации.
***
Проблемы виртуализации
Что такое современный x86-совместимый компьютер? Если кто-то скажет вам, что это довольно простая штука, - не верьте: он просто не знает о чем говорит. Примерное представление о масштабах этой, хм, технологии дает разве что техническая документация - четыре многосотстраничных тома краткой документации по архитектуре IA-32 (The IA-32 Intel Architecture Software Developer’s manual: vol. 1, 2A, 2B amp; 3) и еще два - по ее 64-битным расширениям (The Intel Extended Memory 64 Technology Software Developer’s guide, vol. 1 amp; 2). Впрочем, о последних лучше почитать в первоисточнике - пятитомном издании AMD64 Architecture Programmer’s Manual. Реализовать по этим здоровенным талмудам даже простую имитацию современного x86-процессора - огромная работа; и еще труднее - сделать такую имитацию, которая бы умела более или менее эффективно задействовать для исполнения виртуального кода ресурсы центрального процессора. Даже куда более простая и специально оптимизированная виртуальная машина Java, как известно, работает довольно медленно; надеяться же на чистую эмуляцию средствами центрального процессора чего-либо принципиально более мощного, нежели какой-нибудь ZX Spectrum на процессоре Z80, и вовсе не приходится. Поэтому все современные виртуальные компьютеры идут другим путем - не эмулируя в прямом смысле слова несколько виртуальных ПК, а запуская на одном персональном компьютере несколько операционных систем и ловко «дурача» их, с помощью разных приемов защищая от взаимного «членовредительства» и заставляя «поверить» в то, что кроме них в системе никого нет (рис. 1). Беда в том, что каких-либо приспособлений для подобного рода «надувательства» у этих «виртуализаторов» нет - им приходится выкручиваться, используя для своих целей стандартные методы (IA-32 aka 32-разрядный x86 - весьма гибкая архитектура, и во многих отношениях сделать это оказывается возможным). Однако предусмотреть все ситуации и найти ответы на все возникающие при этом вопросы - практически нереально. Разные ухищрения, на которые приходится пускаться программистам, к сожалению, являются скорее латанием дыр в ветхом днище корабля: для того чтобы кое-как, с половинным ходом доплыть до дока, такого «ремонта» хватает, а вот для длительных морских походов или бурных морей - нет.
Рассмотрим суть возникающих неприятностей на примере так называемой проблемы нулевого кольца исполнения. Кольца (rings, они же уровни приоритета - PLs, Priority Levels) - это такая хитрая система, защищающая центральный процессор от выполнения «посторонними» программами «глубоко системных» инструкций и операций, эдакий «уровень доступа» запущенной программы к системным ресурсам. В IA-32 четыре кольца, от Ring 0 до Ring 3. Чем больше номер кольца - тем меньше приоритет и тем меньше доступно работающей программе. В нулевом кольце запущенный процесс может делать все, что заблагорассудится, - ему предоставлен карт-бланш на любые операции; так что именно в этом кольце «обитает» ядро операционной системы и непосредственно взаимодействующие с оборудованием драйверы. Третье кольцо - сильно упрощенный и ограниченный мирок, в котором запущенный процесс может свободно «жить», но изменить который он не в состоянии. Здесь «живут» всяческие прикладные программы. Кольца 1 и 2 ни Windows, ни *nix-системами принципиально не используются.
В чем же проблема? Оказывается, когда мы «дурачим» виртуальную операционную систему, то не совсем понятно, в какое из колец ее следует помещать. В Ring 0, очевидно, поместить ОС нельзя - проконтролировать ее действия в этом случае не сумеет ни одна живая душа, ибо «воля» исполняющегося в этом кольце кода обсуждению или критике со стороны процессора не подлежит. Поместить операционную систему в «непривилегированные» первое, второе или третье кольца тоже нельзя: любая ОС проектируется, исходя из расчета, что выполняться она будет в нулевом кольце привилегий, а значит, отсутствия необходимого минимума маленьких, но жизненно важных для работы ее ядра инструкций не простит. Вот и приходится программистам либо заблаговременно проверять код на предмет «неблагонадежных» инструкций, ставя на их место вызовы «правильных заменителей», либо отлавливать возникающие при исполнении «неправильных» инструкций ошибки и пытаться их на лету исправлять. Легко догадаться, что реализация и того и другого выливается в большую головную боль для программистов, причем на вроде бы совершенно пустом месте. К примеру, часто «гостевую» операционную систему размещают в неиспользуемом первом кольце… но в расширенном 64-битном режиме процессор не поддерживает кольца 1 и 2, так что все соответствующие наработки «виртуализатор», естественно, отправляет в корзину. Рано или поздно количество проблем переходит в качество - и виртуальные машины становятся не только крайне сложными с программной точки зрения, но и громоздкими, медленными и ненадежными.
***
Искусство обмана. Intel Vanderpool
Так что же делать? Отказаться от надежды на массовый виртуальный ПК? Конечно, нет! Как минимум, вместо того, чтобы заниматься замысловатой оптимизацией кода для хитроумного обмана операционной системы, можно просто внести некоторые изменения собственно в ОС, видоизменив «наиболее мешающиеся» части ядра. Подобный подход называется паравиртуализацией, он активно продвигается компанией Sun и поддержан движением OpenSource… но эту красивую картинку, к сожалению, успешно портит своими «незаменимыми продуктами» великая и ужасная Microsoft, ибо адаптировать сверхпопулярное ядро Windows NT к реалиям конкретной виртуальной машины может, естественно, только его автор; но так, как делать этого софтверный гигант не собирается (слишком уж многое нужно перелопачивать в ядре), то и сам подход получается если не тупиковым, то, по крайней мере, неполноценным. Поэтому куда интереснее второй, гораздо более простой и универсальный способ - аппаратная поддержка функционирования менеджеров виртуальных компьютеров со стороны процессора, то есть технологии виртуализации. Именно так и поступила Microsoft, разработав в тесном сотрудничестве со специалистами VMWare систему, снимающую основную «головную боль» с разработчиков соответствующего ПО.
Центральная идея Intel Virtualization Technology (ранее известной под названием Vanderpool) - введение в процессор аппаратной поддержки некой специализированной программы - менеджера виртуальной машины (VMM, Virtual Machine Manager) (рис. 1). В принципе, VMM - по всем статьям обычная программа, работающая на персональном компьютере. Однако «права» у этой «обычной» программы самые невероятные, поскольку она может вмешиваться во все мало-мальски значимые события, происходящие в процессоре. То есть, если, скажем, ядро операционной системы (работающее в обычном, ничем не ограничиваемом Ring 0) вызывает инструкцию CPUID, или читает-записывает важный системный регистр CR[Что, впрочем, неудивительно - AMD сегодня отвоевывает себе «место под рыночным солнцем», а для этого ей необходимо предлагать более совершенные и интересные решения], или произошло какое-то внешнее событие, вроде прерывания - то процессор сообщает об этом VMM и… больше ничего не делает, предоставляя VMM право реагировать на возникшее событие самостоятельно. Менеджер виртуального ПК «разбирается» в происходящем, решает, как поступить (например, может, необходимо после нажатия какой-то кнопки переключить CPU на другую запущенную операционную систему), и «программно» имитирует действия центрального процессора в подобной ситуации. Причем отслеживать разные события ему приходится довольно интенсивно: «вручную» маршрутизировать обращения операционных систем к периферийным устройствам, «вручную» загружать и переключать запущенные операционные системы, «вручную» следить за виртуальной памятью запущенных операционных систем, чтобы последние нечаянно не «покалечили» друг друга, считая себя единственными претендентами на имеющиеся физические ресурсы.
Последний пример хорошо иллюстрирует суть происходящего. Как известно, современные многозадачные операционные системы активно используют механизм виртуальной памяти, когда запущенные на процессоре программы работают с «линейными» адресами, произвольным образом отображенными в реальную физическую оперативную память (или еще куда-нибудь - например, на участок жесткого диска в своп-файле или своп-разделе). С физической памятью не работает даже сама операционная система: слишком уж это неудобно - подстраиваться под особенности конкретного ПК, и слишком опасно - когда в общей куче перемешаны данные десятков и сотен запущенных программ, и только аккуратность разработчика защищает эти данные от ошибочных действий программного обеспечения. Преобразование виртуальных «линейных» адресов в физические обычно выполняет сам центральный процессор, для чего у него предусмотрена специальная таблица трансляции адресов, в которой записано, какому «линейному» адресу какой физический соответствует (или стоит пометка, что при обращении к данному участку памяти процессору следует позвать на помощь операционную систему). Хранится эта таблица не в регистрах процессора, а в оперативной памяти (в виде трех-четырехуровневого B-дерева, если вас интересуют подробности), причем таблиц может быть сколько угодно: для переключения к другому виртуальному адресному пространству в процессоре достаточно изменить один-единственный регистр CR3 (указатель на таблицу трансляции) и выполнить специальную команду сброса и очистки кэшей CPU, в которых может сохраняться старая информация о виртуальной памяти. «Простым смертным» в лице обычных программ доступ к CR3, разумеется, закрыт, и поэтому изменить «мир», в котором программы находятся, они могут только путем обращения за помощью к операционной системе. Операционной системе «проще» - она, с одной стороны, подчиняется «общим правилам», а с другой - может эти правила самостоятельно «переписывать», работая ровно в тех условиях, которые кажутся ей наиболее приемлемыми. Скажем, если ОС срочно потребуется записать что-то по физическому адресу 0x00123456, она вначале создаст в таблице трансляции своих виртуальных адресов ссылку на соответствующий участок оперативной памяти (отобразив его в то место виртуального линейного пространства ОС, которое покажется ей самым удобным) и затем обратится по свежесозданному виртуальному адресу. Для «обычного» же процесса (который, строго говоря, почти ничем не отличается от процесса ядра операционной системы) подобная «лазейка» к, скажем, «соседям» по компьютеру закрыта - ему просто-напросто не дадут увидеть собственную таблицу трансляции, выведя ее за пределы «видимости» виртуального пространства его памяти либо защитив эту область памяти от записи (здесь тоже используется та самая таблица трансляции - в ней можно указывать права доступа к виртуальным адресам). Все замечательно, все удобно, никаких проблем.
Но стоп, - скажет здесь читатель, - а что же будет, если мы запустим две операционные системы и одна из них решит отобрать для своих целей кусочек физического, а не виртуального пространства памяти другой операционной системы, отобразив его в своей таблице трансляции? В обычных условиях это фатальная ошибка, которая быстро приведет две совместно работающие операционки к краху. Но если у нас есть VMM, то ситуация в корне меняется, ибо мы теперь можем запущенную операционную систему «одурачить», перехватив соответствующее обращение и подсунув ей не настоящий CR3, а специально подготовленную «пустышку». ОС, наивно полагая, что она полностью контролирует виртуальную память компьютера, на самом деле будет всего лишь изменять никак не связанную с настоящей таблицей трансляции область оперативной памяти. А обращения к ней, используя стандартные же механизмы виртуальной памяти, будет перехватывать все тот же VMM и синхронизировать в соответствии с ними настоящую таблицу трансляции. Красиво придумано, не правда ли? Собственно виртуальной машины у нас нет, просто мы тщательно контролируем работу операционной системы и при необходимости ловко манипулируем ею.
Набор ситуаций, «прерывающих» выполнение обычных программ и приводящих к вызову VMM, довольно гибко настраивается - вовсе не обязательно, скажем, реагировать на все обращения операционных систем к компьютерным портам ввода-вывода: достаточно указать, какие порты для какой операционной системы будут «выбрасывать» ее к VMM, а какие - работать как если бы VMM не существовало в природе. Причем догадаться о том, что ОС запущена «под неусыпным контролем», практически невозможно: VMM может, например, точно таким же образом фальсифицировать обращения к CPUID (информация о процессоре и поддерживаемых им технологиях), после чего запущенная на Pentium D операционная система будет искренне полагать, что работает, скажем, на Pentium 3 и что никакой поддержки технологий виртуализации этот процессор не предоставляет.