CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
25.07.2016

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

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

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

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

В своей первой заметке я пытался объяснить публике, почему 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 открытыми и создать международное сообщество. Возможно, тогда сегодня мы бы работали с более технологичными операционными системами.

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




Комментарии

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

аноним, Tue Oct 13 22:35:12 2009:
Намудрили сами не пойми чего. Кластеры-хуястеры, ядра-хуядра. А как там с аськой?
аноним, Tue Oct 13 20:48:46 2009:
Давно уже есть. В СССР была "Сетунь", в Штатах ещё какие-то машины были, только я про них ничего не знаю.


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

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

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

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

Интересно, что подразумаваетца под серъёзной работой?
аноним, Thu Feb 12 14:35:07 2009:
>аноним, четверг, 12 февраля 2009 г. 11:08:30:
>Но, к сожалению даже попытки установить Ubuntu alternate-powerpc и server-powerpc закончились провалом.
O_o
Сфотографируй руки и вышли снимок!

>А так же хвала разработчикам программ для видеомонтажа (нет ничего подобного Apple - Final Cut Studio для других систем) и дизайна.

Слушай, а как тебе удаётся одновременно заниматься профессиональным видеомонтажом и профессиональным дизайном? Или просто врёшь?

>Евгений Шаталов, четверг, 12 февраля 2009 г. 11:12:58:
>Есть замечательная «старая» архитектура, PPC называется. Не чита x86 логике.

Только она дорогая. Потому похоже, что и сдохла.
Евгений Шаталов, Thu Feb 12 11:12:58 2009:
«Пока не будет новой процессорной архитектуры»
— Есть замечательная «старая» архитектура, PPC называется. Не чита x86 логике.
аноним, Thu Feb 12 11:08:30 2009:
Mac OS X рулит! А так же хвала разработчикам программ для видеомонтажа (нет ничего подобного Apple - Final Cut Studio для других систем) и дизайна. Если юзабилити и софтерное наполнение для других сред будет на уровне Mac OS (хотя в основе её всё тот же Unix/Darwin) с радостью буду ставить и работать и в них. Но, к сожалению даже попытки установить Ubuntu alternate-powerpc и server-powerpc закончились провалом. Ну, а Винда так вообще для тех, кто рождён страдать. Кого-то еще не заебала винда со своими лагами, не стабильностью и ебаным голубым экраном смерти...?
Олег, Wed Feb 4 19:52:47 2009:
Сергей, спасибо за статью. Сначала не хотел ничего писать, много времени прошло. Но, почитав комментарии, не удержался. Недавно посмотрел программу подготовки в местном институте и ужаснулся! ВУЗ превратился в КУРСЫ по вполне определенным программным продуктам!!! Какая там наука, какие там исследования!? Basic, Pascal, электронные таблицы, PHP - это верх компьютерных специальностей ВУЗа!!!
Большинство нынешних комментариев - это продукт деградации нашей системы образования. Это печально!
Продолжайте писать - у вас есть еще свой читатель!
аноним, Tue Dec 23 13:06:05 2008:
2 аноним, вторник, 23 декабря 2008 г. 12:11:50:

мне помогли спектурм, корвет и ямаха. после бейсика и машинных кодов оставалось только освоиться в другой среде и с другим языком. опыта набраться.
аноним, Tue Dec 23 12:11:50 2008:
вот в те лохматые 80-е когда жалкое Atari стоило в комках 8000 руб а зарплата моего отца была 180 руб, а я был просто старшеклассник ..вот тогда за собственные деньги мы с отцом убедились что хорош тот компьютер под которым куча софта и все эти Агаты (аналог Apple II) и УКНЦ (ДВК 3 аналог Dec) всё это кануло в лету .... только интел помог стать программистом ..да и на интел небыло никакой документации ..какого вам без инета без документации изучение BASIC -а по helpу ? нет методом тыка INPUT - наверное что то вводит PRINT наверное что то печатает ..выкиньте ваши мысли о поделках ...если конечно вашу научную деятельность не субсидирует IBM. Даже тот же Билл Гейтс не был бы сейчас билл гейтсом если бы не IBM ..то есть за ваши "а может быть попробуем так" должен кто то платить ...а в Linux до сих пор нет коммерческих драйверов для всех видео карт ...я это уже испробовал Open Gl разработанный в те самые 80-е до сих пор на Linux моргает мерцает и прочее .... когда все объединяются и улучшают что то одно то эта вещь становится в итоге самой лучшей ... ежели каждый будет лобать СВОЮ операционную систему а потом крестить программистов в свою веру ..то он так и останется разработчиком неизвестно чего. Извиняйте за тон ..за больное задело просто :-) а вообще всех с наступающим и больше хороших и разных программ которые можно будет запусать вместе в одной ОС !

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

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds