Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Альтернативные ОС: две грустные истории

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

Теперь мне хочется немного поговорить об операционных системах, при проектировании и разработке которых преследовалась цель сделать действительно что-то принципиально новое, а не создать еще одну реализацию системы с известными функциональными возможностями и интерфейсом. Таких попыток было много, но я остановлюсь на двух из них: российском проекте КЛОС (кластерная операционная система), активным участником которого был я сам, и французском – Chorus, который выполнялся практически в одно время с КЛОС.

Для кого это пишется? Конечно, не для тех людей, которых вполне удовлетворяет длящаяся уже около трех лет болтовня о «великом противостоянии». Я очень прошу их не отвлекаться от этого захватывающего развлечения и не тратить свое драгоценное время на чтение и комментирование моей заметки. Однако есть еще люди, которым интересны операционные системы вообще, которым интересны разработка, программирование и отладка сложных приложений, и которых не всегда и не вполне удовлетворяют возможности ОС, используемых в массовом масштабе в настоящее время (во избежание нездоровой сенсационности и дабы угодить отдельным критикам не буду их называть; замечу лишь, что здесь меня интересует только техническая сторона вопроса, а не способ разработки, политические и маркетинговые аспекты). Эта заметка для них.

Конечно, многое можно прочитать в книгах про операционные системы, но их авторы обычно избегают эмоций, стремясь к объективности. Мне же хотелось написать абсолютно субъективный текст, опираясь на собственные воспоминания. Почему мне захотелось поговорить именно про КЛОС и Chorus? Во-первых, обе эти системы были микроядерными. Этот подход был очень популярен, начиная с середины 1980-х гг., и в КЛОС и Chorus использовался в чистом виде (т.е. в состав микроядра включались действительно минимальные средства ОС с точки зрения их общей организации). Во-вторых, оба проекта были инициированы и выполнялись в академических государственных институтах (INRIA во Франции и Институте проблем кибернетики академии наук СССР), в отличие, например, от проекта Mach, который выполнялся в американском университете Карнеги-Меллон. В-третьих, участникам обеих проектов, хотя и по разным причинам, не удалось добиться своих исходных целей. Наконец, в-четвертых, участники обоих проектов пристально следили за родственными проектами (тем же проектом Mach, проектом Эндрю Таненбаума Amoeba и т.д.).

Конечно, у проектов КЛОС и Chorus имелось и множество важных различий. КЛОС проектировалась и разрабатывалась в Советском Союзе, который в середине 1980-х гг. был все еще страной, изолированной от международного сообщества. Chorus разрабатывалась международной командой в лучшем исследовательском институте Франции при наличии контактов с исследовательскими группами в других странах. КЛОС создавалась практически на общественных началах без какого-либо отдельного финансирования во время, когда участники проекта не были заняты другими делами. Проект Chorus был официальным финансируемым проектом INRIA, его участники работали в проекте полный рабочий день. Наконец, после завершения исследовательской стадии на основе результатов проекта Chorus была основана коммерческая компания Chorus Systems (хотя и не слишком удачная), а проект КЛОС был просто закрыт.

В этой заметке я посвящу основное внимание КЛОС, поскольку по естественным причинам эта система мне ближе. Кроме того, в отличие от КЛОС, про Chorus в Internet можно найти хорошие статьи, так что читатели смогут напрямую познакомиться с подробностями, которые здесь будут опущены.

КЛОС: влияние смены общественного строя на проекты операционных систем

Как я писал в своей первой заметке этого цикла, к проекту КЛОС мы приступили после окончания работ над операционной системой вычислительного комплекса АС-6. Точнее сказать, в АС-6 использовались три операционные системы: созданная ранее ОС НД-70 для БЭСМ-6, универсальная операционная система ОС ЦП нового процессора, который назывался ЦП АС-6, и специализированная операционная система ОС ПМ-6 периферийной машины, которая в АС-6 отвечала за обслуживание внешних устройств и линий связи.

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

Такой способ организации виртуальной памяти естественным образом приводил к организации операционной системы, которая погружалась в каждую виртуальную память, занимая в ней сегменты с наиболее высокими уровнями защиты (естественно, каждый такой сегмент отображался на страницы основной памяти через единую таблицу страниц). Тем самым, в ОС ЦП при разработке даже самых внутренних частей ядра приходилось учитывать возможность одновременного наличия нескольких потоков управления. Для работы с общей памятью использовалась явная синхронизация на основе двоичных семафоров и событий в стиле ОС IBM/360.

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

Я все это говорю не для того, чтобы рассказать про устройство ОС ЦП (это была сложная операционная система, которую невозможно описать на страничке текста), а лишь затем, чтобы заметить, что при программировании и самой ОС ЦП, и приложений в ее среде приходилось использовать явную синхронизацию при работе с ресурсами, общими для нескольких потоков управления. И после многолетней работы в таком режиме мы пришли к выводу, что сложность отладки таких программ, неповторяемость проявления ошибок, трудность понимания кода требует поиска других принципов построения операционной системы. К аналогичным выводам пришли коллеги, разрабатывавшие НД-70 и ОС ПМ-6. Вместе с тем, наc не удовлетворял жесткий синхронный стиль взаимодействия процессов с устройствами и между собой, который существовал в тогдашней ОС UNIX.

Исходная идея «асинхронного кластера» принадлежит В.П. Иванникову. Фактически она состоит в связывании понятий многовходового программного модуля, виртуальной памяти и потока управления. В виде кластера реализуются компоненты операционной системы и приложений, которым требуется собственная активность. У кластера имеется собственное состояние, в соответствии с которым он допускает обращения к тем или иным своим входам со стороны других кластеров. При обработке этих обращений состояние кластера может меняться. Основная функция ядра ОС состоит в поддержке взаимодействий кластеров (не считая, конечно, планирования процессора, обработки прерываний и т.д.).

К началу 1980-х гг. у группы молодых программистов, занимавшихся операционными системами АС-6, появилось некоторое свободное время, и было решено использовать его для разработки новой операционной системы, основанной на идее асинхронного кластера. Систему назвали КЛОС (КЛастерная Операционная Система). Поначалу это была чисто исследовательская работа без явной цели получить реально функционирующую ОС для какого-либо конкретного компьютера. Для упрощения первых разработок и обеспечения их независимости от особенностей реальной аппаратуры было принято решение разрабатывать первый вариант поверх операционной системы UNIX. Впоследствии этот вариант систем был доработан и перенесен на платформу рабочей станции Беста (процессор Motorola 860x0), и уже над ним была реализована стандартная среда UNIX.

Основу КЛОС составляло микроядро, поддерживающее шесть примитивов: ПУСК, СТОП, ПОДКЛЮЧЕНИЕ, ОТКЛЮЧЕНИЕ, ЗАГРУЗКА, РАЗГРУЗКА. У каждого кластера статически описывались входные точки (входы), которые статически же объединялись в группы входов. Например, у кластера управления файлом могли бы иметься входы Открыть_на_чтение, Открыть_на_запись, Читать, Писать и Закрыть, объединенные в следующие группы входов: (Открыть_на_чтение, Открыть_на_запись), (Читать, Писать, Закрыть) и (Читать, Закрыть). Для обращения от кластера-клиента к некоторому входу некоторой группы входов кластера-сервера клиент должен был обладать дескриптором подключения к этой группе входов, являющимся защищенным объектом микроядра. Дескрипторы подключения к некоторым группам входов (статическим, таким как группа входов (Открыть_на_чтение, Открыть_на_запись) кластера управления файлом) клиенты могли получать статически на стадии компоновки подсистем (см. ниже). Дескрипторы подключения к другим группам входов (динамическим, таким как группа входов (Читать, Закрыть) кластера управления файлом) кластер-сервер мог формировать динамически, используя примитив ПОДКЛЮЧЕНИЕ, и передавать клиенту в качестве ответного параметра на обращение к некоторому другому входу (например, входу Открыть_на_чтение кластера управления файлом).

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

После выполнения примитива ПУСК кластер-клиент продолжал свое выполнение, а аргументы этого примитива буферизовались в памяти микроядра до тех пор, пока соответствующий кластер-сервер не выполнял примитив СТОП, указывающий микроядру, что он готов принять обращение по данному входу (основным параметром примитива являлся список номеров входов кластера, обращающегося к микроядру с этим примитивом). Естественно, если предполагалось получение кластером-клиентом от кластера-сервера некоторых ответных параметров, то в число параметров обращения должен был входить дескриптор некоторой группы входов клиента. В общем случае взаимодействия кластеров были полностью асинхронными (с синхронизацией на основе примитивов СТОП), но легко реализовалась и схема синхронных взаимодействий, при которой кластер-клиент передавал кластеру-серверу дескриптор подключения к своей специальной группе входов и выполнял примитив СТОП сразу же после выполнения примитива ПУСК.

Обращения к кластеру-серверу по некоторым специальным входам (входам отстройки, таким как вход Закрыть кластера управления файлами) обрабатывались микроядром специальным образом, а именно, кластеру-серверу передавался и сам дескриптор подключения, через который производилось обращение. После этого, естественно, кластер-клиент больше не мог обращаться к данному кластеру-серверу через этот дескриптор. Кластер-сервер мог выполнить по отношению к любому дескриптору подключения к своей динамической группе входов примитив ОТКЛЮЧЕНИЕ, что приводило к немедленной ликвидации этого дескриптора, если он принадлежал серверу, или блокировке последующих обращений, аварийной обработке уже произведенных, но еще не обработанных обращений и ликвидации дескриптора, если он принадлежал некоторому клиенту.

Каждый кластер обладал собственной виртуальной памятью, а также рядом сегментов. Сегменты могли быть статическими (сегмент кода и сегмент «локального поля», аналогичный сегменту данных в UNIX), постоянно отображаемыми в виртуальную память, и динамическими (получаемыми от других кластеров, в том числе, от специального «привилегированного» кластера распределения памяти), отображаемыми в виртуальную память с использованием примитива ЗАГРУЗКА. Обратный примитив РАЗГРУЗКА позволял освободить виртуальную память кластера от ранее загруженного в нее сегмента. У каждого сегмента имелся системный дескриптор, который использовался в качестве аргумента примитива ЗАГРУЗКА и мог передаваться другим кластером в качестве параметра примитива ПУСК. Передача сегмента приводила к смене его владельца.

Для формирования функционально полных программных систем и образования загрузочных моделей использовался механизм подсистем. В общем случае подсистема – это статически определенный набор подсистем со статически установленными связями. Элементарной подсистемой является кластер. Как и у кластера, у подсистемы имеются входы и группы входов, но они, вообще говоря, ведут к разным кластерам этой подсистемы. При описании подсистемы задаются все внутренние связи, которые заменяются на дескрипторы подключений к статическим группам входов кластеров, входящих в подсистему, на стадии загрузки. Кроме того, у подсистемы могут иметься внешние связи, которые разрешаются при включении этой подсистемы при ее использовании в качестве компонента более широкой подсистемы или при создании загрузочного модуля этой подсистемы. В последнем случае подсистема загружается параметризованным загрузчиком, у которого имеются все подключения к статическим группам входов, являющимся внешними для данной подсистемы. Для проектирования и определения подсистем поддерживался специальный язык ПроКЛОС.

Для повышения эффективности работы приложений можно было на основе ранее построенных и отлаженных подсистем производить «коммунальные» подсистемы, в которых все кластеры статически компоновались и помещались в единое адресное пространство. Тем самым все межкластерные взаимодействия в коммунальной подсистеме происходили без обращения к микроядру (естественно, с утратой асинхронности).

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

До завершения проекта КЛОС в ее среде была реализована оригинальная файловая система (похожая на современные файловые системы UNIX) и начата реализация полномасштабной SQL-ориентированной СУБД, которая впоследствии превратилась в GNU SQL Server для UNIX. Как уже говорилось, для заманивания новых пользователей в среде КЛОС был реализован достаточно полный эмулятор UNIX.

Почему же проект КЛОС пришлось закрыть? Мне кажется, что тому имеется несколько причин. Во-первых, в лучшие годы проекта не было Рунет, и мы не могли сформировать широкое сообщество КЛОС. Во-вторых, в России наступило очередное смутное время, и не было никакой надежды, что появится какая-то новая отечественная аппаратная разработка, нуждающаяся в операционной системе (поначалу мы на это надеялись). Наконец, мы не могли получить подробную техническую документацию по западным компьютерам и поэтому не были в состоянии перенести КЛОС на какую-либо платформу, отличную от Бесты.

Как я уже говорил, в Internet можно найти крайне мало информации о КЛОС, но одна публикация все же доступна. Наверное, она более содержательна, чем эта моя заметка.

Chorus: чем кончаются коммерческие попытки академических исследователей

Как уже говорилось, проект Chorus выполнялся во французском научно-исследовательском институте INRIA. Проект был начат в 1980-м г. и имел статус исследовательского до 1986-го г., когда была образована коммерческая компания Chorus Systems с целью вывода этой системы на рынок.

ОС Chorus, как и КЛОС, была микроядерной, хотя при проектировании микроядра (Nucleus) преследовались существенно другие цели. Как утверждали авторы проекта в одной из своих основных публикаций, при разработке Chorus они не ставили своей целью создание новой законченной операционной системы, а хотели обеспечить единую среду на основе Nucleus для новой (распределенной) реализации ряда известных операционных систем, в частности, UNIX. Это утверждение немного расходится с моими воспоминаниями. В Nucleus поддерживались стандартные для микроядра функции обработки прерываний, управления основной и виртуальной памятью и т.д., а также поддерживалось большое число разнообразных средств синхронизации и взаимодействия процессов. Основным отличием Chorus от других микроядерных ОС было то, что на уровне Nucleus обеспечивались средства взаимодействия процессов, выполняемых в разных узлах сети (негарантированная передача сообщений и вызовы удаленных процедур), и поддерживалась распределенная виртуальная память. Мы считали, что при наличии таких возможностей микроядра (и некоторых дополнительных средств ОС, реализованных вне него) можно очень удобно создавать распределенные приложения.

Кроме того, нас в то время очень привлекало одно из базовых понятий Chorus – актор (actor), представлявшее собой неразрывную связь программного модуля, виртуальной памяти и потока управления, т.е. очень сильно напоминавшее понятие нашего кластера. Более того, в начале проекта его участники говорили о своем желании разработать на основе Nucleus полноценную объектно-ориентированную операционную систему, которая, как нам казалось, должна была бы напоминать КЛОС. К сожалению, до этого руки разработчиков Chorus так и не дошли.

Тогда нам казалось (возможно, по аналогии с историей КЛОС), что участники проекта Chorus выполнили свою собственную реализацию расширенной среды ОС UNIX (в виде распределенной системы) именно для того, чтобы привлечь внимание широкого класса разработчиков приложений к собственным возможностям Chorus. Возможно, так оно поначалу и было, но реализация UNIX над Nucleus (названная авторами MiX) оказалась настолько удачной и эффективной (в те годы она считалась лучшей реализацией UNIX в Европе), что разработчики Chorus решили сделать на нее отдельную коммерческую ставку. При поддержке INRIA участники проекта основали собственную компанию Chorus Systems, которая активно занялась не пропагандой и агитацией идей Chorus, а попытками коммерческого распространения MiX.

Не могу ручаться, но, по всей видимости, конкурировать с американскими поставщиками UNIX в Европе Chorus Systems не смогла. Может быть, еще и по той причине, что основной платформой MiX являлся Intel x86, а в то время очень хорошие (и признанные в Европе) UNIX-системы для этой платформы поставляла компания Santa Cruz Operation. В конце концов, в 1997 г. Chorus Systems была приобретена компанией Sun Microsystems, которая решила использовать Chorus в качестве операционной системы для встроенных систем. Вроде бы, на основе Chorus была выполнена реализация одного из вариантов Solaris. Однако широкие народные массы про Chorus слышать перестали.

С 2002 г. компания Chorus Systems открыла коды Chorus и перестала поддерживать систему. Участники группы Chorus из Sun (среди которых нет участников оригинального проекта Chorus) основали компанию VirtualLogix, занимающуюся средствами виртуализации систем реального времени (возможно, на основе Chorus).

Так что и проект Chorus нельзя назвать особенно счастливым, хотя у него было больше шансов, чем у КЛОС, поскольку он выполнялся в открытой Франции, входящей в развитую мировую IT-инфраструктуру, основывался на более традиционных идеях и поддерживался государством в финансовом отношении. Мне кажется, что здесь повредило раннее желание INRIA и участников проекта Chorus коммерциализировать проект. В отличие от нас, у французов имелась возможность сделать коды Chorus открытыми и создать международное сообщество. Возможно, тогда сегодня мы бы работали с более технологичными операционными системами.

Итак, оба кратко рассмотренных проекта нельзя считать вполне удачными. Однако, вне всякого сомнения, оба они принесли громадную пользу участникам проектов и в некоторой степени способствовали общему развитию технологии ОС. Как я писал в первой заметке, хочется надеяться, что это когда-нибудь еще пригодится.

CITKIT.ru
Цикл "Операционные системы:
Ностальгия по будущему
"

Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: ... :: 5 :: следующая

аноним, Ср 12 июн 2013 17:01:13:
Бартоломео
Франческо
Растрелли
хм... ну и сайт. Дилетанты.
аноним, Ср 12 июн 2013 16:58:54:
> министр обороны США расказывает Обаме о инопланетянах амфибиях (мол, у нас никто ракет не крал).

Наслушался сказочек на каникулах? )))

> Закосил под дурака, ведь дураков в демократической стране лечат, а не растрелливают.

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

* "растрелливают" - ты думаешь, это слово произошло от имени Бартоломе́о Франче́ско Растре́лли?
Ошибаешься. Посмотри в словаре и запомни правильное написание.
аноним, Ср 12 июн 2013 13:09:49:
>аноним, Срд 12 Июн 2013 06:30:03:

аноним, в любом случае это очень узкоспециализированная тема для очень узкого круга исследователей и исполнителей и никак не для широкого обсуждения.
и не забывай, что кроме бумаги (кода) нужно железо, чтобы что-то реализовать свое. точнее это надо лабать все одновременно.
и тут на сцену должен выйти бизнес, но он зажат в узких рамках.
можно уповать на государство, но я очень сомневаюсь, что наши компрадоры решаться идти против вашингтонского обкома и в ссср, в 70-х, судьба развития IT уже была предрешена.
это конечно мое мнение, но слишком много очевидных свидетельств того и ностальгия автора статьи по убитым пороектам лишний раз подтверждает мое мнение и говорит о его непонимании того, что произошло.
хотя, люди его уровня не должны говорить всего и он просто тоскует по молодости.
аноним, Ср 12 июн 2013 06:30:03:
Для аноним, Втр 11 Июн 2013 19:42:11
Не всё решает рынок, к примеру, знаеш ли ты конкретно, какая ОСь стоит на серверах пентагона или министерсва обороны России? Например допустим все (почти) ОСи могут исполнять файлы с расширением *.BIN (условный пример), "вписываем" микроядерную ОСь в виря (правильнее сказать скрипт действий в ОС) и "подсовываем на исполнение". Врезультате допустим 52% компьютеров пентагона "замерзают" и сливают по шнуровому интернету содержимое оперативы на серверы в скажем Китае, после чего "у нас" с подводной лодки торчащей в Тихом океане "сбегает" ракета, а министр обороны США расказывает Обаме о инопланетянах амфибиях (мол, у нас никто ракет не крал). Закосил под дурака, ведь дураков в демократической стране лечат, а не растрелливают.
Микроядерные ОС можно использовать в качестве кибер-оружия и к чёрту бизнес, если "врага" можно уничтожить его собственным оружием, подключенным к "правильным" компьютерам.
аноним, Вт 11 июн 2013 19:42:11:
автор живет в мире иллюзий не понимая, что мир IT жестко монополизирован.
те ОС, котороые имеются, удовлетворяют запросы рынка и финансовые группировки успешно эксплуатируют эти запросы.
а даже если и не удовлетворяют в отдельных случаях, то рынок подстраивается под то, что имеется.
никто не будет желать того чего нет или того, что неизвестно.
ddd, Вт 11 июн 2013 17:51:23:
А мне непонятны придыхания автора по поводу открытой мировым ветрам Франции и замкнутой СССР.

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

Проблем-то не было, был вопрос только финансирования для поездок за рубеж. А если автор и иже финансирования достаточного не добились, то и проект был внутренним.

Кстати сказать, если француз (или американец) не получает финансирования на поездки за рубеж, то он не ноет о закрытой стране.
bmooh, Вт 11 июн 2013 10:28:46:
http://beosway.ru/?q=node/73 - Sakura 0.6 - дистрибутив haiku OS
аноним, Вт 13 окт 2009 20:48:46:
Давно уже есть. В СССР была "Сетунь", в Штатах ещё какие-то машины были, только я про них ничего не знаю.


Сетунь это река!
аноним, Вт 13 окт 2009 20:48:03:
>Интересно, что подразумаваетца под серъёзной работой?

Самая серьезная работа это дзен и созерцание куба compiz, только так можно достич анальной доминации либеральных ценностей в одной конкретной единице хуеты.
аноним, Вт 17 фев 2009 13:33:58:
2аноним, четверг, 12 февраля 2009 г. 11:08:30:
Кого-то еще не заебала винда со своими лагами, не стабильностью и ебаным голубым экраном смерти...?

Маладой челавег ви есчо 3,11 пользуетесь? О_о
Кстате, BSOD можно перекрасить :))

2AntiAleX, вторник, 23 декабря 2008 г. 04:45:53:
а для любой серьёзной работы и Linux

Интересно, что подразумаваетца под серъёзной работой?

Страницы комментариев: 1 :: 2 :: 3 :: ... :: 5 :: следующая

Ваш комментарий

Имя:

Текст комментария (HTML-теги не допускаются):

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...