Приглашаю вас принять участие в разработке операционной архитектуры Octopus  (рабочее название). Выкладываю файл тезисов описания – основной файл текущей документации, в котором (как надеюсь) логически строго и непротиворечиво описано текущее видение системы.

Это сообщение отредактировал(а) Абабо - 4.8.2007, 21:44

Присоединённый файл ( Кол-во скачиваний: 69 )
 ________.rar 20,65 Kb

Выкладываю краткий сравнительный анализ операционных архитектур и их сравнение с разрабатываемой.

Присоединённый файл ( Кол-во скачиваний: 43 )
 ____________________________________.rar 94,09 Kb

Выкладываю сборник разнородных (порою противоречивых) документов, призванных скорее не представить целостный концептуальный взгляд, а проиллюстрировать ход мыслей.

Добавлено через 3 минуты и 23 секунды
Мои координаты для заинтересованных: 
E-mail: [email protected]
ICQ: 256076976

Буду рад обсудить любые идеи, качающиеся архитектуры операционных систем.

Присоединённый файл ( Кол-во скачиваний: 31 )
 ____.rar 44,18 Kb

А что насчёт совместимости с существующими системами? Ну или хотя бы с оборудованием?

Это сообщение отредактировал(а) anonym - 4.8.2007, 22:10

Совместимости с существующими платформами не предусматривается (по крайней мере на этом этапе), но безусловно учитываются особенности архитектуры современных процессоров.

Это сообщение отредактировал(а) Абабо - 4.8.2007, 22:30

Абабо, хоть одна строчка кода уже есть?   

Нет. В ближайшее время не появится. Рано.

Какая цель создания этой ОС? На чем пишите? 

P.S. Где живете?

Это сообщение отредактировал(а) lostinwired - 5.8.2007, 23:28

Вообще, это тема моего НИРСа (ещё учусь)... наверняка, и дипломной работы в последствии. 

По поводу цели... вот цитата одной моей статейки (простите за напыщенность - писал преподавателю):


1.1 Что такое Octopus?

Octopus – распределённая мультиплатформенная масштабируемая операционная система (ОС), надстраивающая над разнообразными устройствами хранения и переработки информации, соединённых друг с другом в сеть, единое стандартное информационное пространство. 

1.2 Зачем Octopus?

В связи с всё возрастающими потоками информации, становится всё труднее ориентироваться в многообразии самых разнообразных данных. Поисковые возможности внутри информационного поля сильно ограниченны малым количеством ссылок и метаинформации. Вследствие стандартизации информационного поля, развитой концепции типов и метаинформации, а также многосвязности данных Octopus должна обеспечить беспрецедентные возможности поиска информации, как на локальной машине, так и в глобальной сети.

Писать планирую на Си (наверное, gcc).

Живу в Украине, в Донецке.

P.S. Если заинтересованы составить представление об архитектуре Octopus - читайте файл тезисов описания.

Проект интересный.

Абабо, желаю удачи! (В хорошем смысле)
От себя хочу добавить только следующее:
 1) Си конечно хорошо, но ОСи писать надо на АСМе. И не верь тем, кто говорит, что это мазахозм ибо ядро написанное на АСМе будет гораздо лучше.
 2) Сформулируй концепт-документ (ибо те доки что ты выложил - (если смотреть объективно) филькина грамота) и спланируй график работ (если этого еще не сделал). Если тебе доводилось в ВУЗе до этого писать научные роботы, то оформление доков не станет для тебя проблемой. Если нет - скачай в нете чью-нибуть работу и посмотри как это делается.
 3) Если чесно, "идеи" (коих толком нет) не впечатлили и это все больше похоже, что будет банальная затея в духе "мега-крутая ОС для хацкеров от Васи Пупкина". Надеюсь, что это только начальное впечатление.
 4) Какие платформы заюзать хочешь?
 5) Как на счет графической оболочки. В консоли то "организация удобного доступа к файлам" из области НЛО.
 6) Сетевая ОС ИМХО хорошо, но без поддержки стандартов кому она нужна будет? Как ты, к примеру, с маршрутизаторами сиськи собираешься общаться?
 7) А кому нужна будет собственно говоря твоя ОСь без поддержки основных стандартов? Вариант ОС для программистов и сисопов уже не раз поднимался и нечего толкового не принес. ;) 
 8) Формат исполняемых файлов?...
 9) А на чем тестировать собираешься?...
 10) Возможность наличия нескольких ОС на одном компе?...
Эт те для размышления...

Не буду комментировать. 

Выкладываю обновлённую версию тезисов в pdf формате.

Присоединённый файл ( Кол-во скачиваний: 20 )
 ________.part1.rar 88,13 Kb

Не поместился - вот вторая часть...

Присоединённый файл ( Кол-во скачиваний: 16 )
 ________.part2.rar 87,48 Kb

Ну да... ну да... и переписывать все ядро, при портировании на другую архитектуру. Так чем лучше?


1. Существует X Window System 
2. Консоль как ни крути довольно удобная штука

Абабо, 
Чем оно лучше уже существующих ОС (Не считая того что оно НИРС)?

P.S. Все вышесказанное - мое непросвещенное мнение и сугобое ИМХО

Целей имеется несколько. 
Первая заключается в попытке построения красивой и концептуально простой архитектуры, подобной UNIX, однако базирующейся на объектно-ориентированных представлениях. Вторая – обеспечить полноценную поддержку распределённым вычислениям и клиент-серверному взаимодействию (чтобы web-приложения не нужно было базировать на интерфейсе браузера, без AJAX и ей подобных технологий). Третья – обеспечить единую систематику форматов данных (за счёт общей для всех системы типов и интерфейсов), хранимых и обрабатываемых различными по назначению и мощности устройствами, что должно обеспечить высокие поисковые возможности как в интернете, так и на локальной машине. 

Тогда советую посмотреть на Plan9 http://plan9.bell-labs.com/plan9/
на инферно http://www.vitanuova.com/inferno/

Skladnoy, спасибо вам за ссылки - было интересно почитать. Выкладываю по частям начальную схему интерфейсов нескольких базовык классов (документ MS Visio).

Присоединённый файл ( Кол-во скачиваний: 17 )
 ________.part1.rar 100,00 Kb

Вот вторая часть документа.

Присоединённый файл ( Кол-во скачиваний: 16 )
 ________.part2.rar 64,95 Kb

Скоро приступаю к написанию текста, популярно и доходчиво поясняющего тезисы описания. Параллельно перерабатываю зародыш иерархии классов со схемой интерфейсов - где-то через неделю будет документ MS Visio с описанием ветви иерархии вплоть до System.Type включительно. 

Приглашаю вас принять участие... готов обсудить и пояснить детали 

Выкладываю обещанную часть иерархии в pdf-документе:

Это сообщение отредактировал(а) Абабо - 2.10.2007, 20:37

Присоединённый файл ( Кол-во скачиваний: 43 )
 Hierarchy_.pdf 38,34 Kb

Все современные ядра уже давно на асме никто не пишет.
Асм не дает никакой пеерносимости, под любую новую архитектуру придется переписывать все заново.
Так что правильно что чел выбрал С, чтобы написать на асме лучше чем на С надо досконально знать архитектуру и сам асм, что может быть будет только при многолетнем опыте работы с последними. Современные компиляторы все уже давно лучше оптимизируют чем программист.

Начал писать описание - выкладываю то, что успел набросать (часть первая).

Присоединённый файл ( Кол-во скачиваний: 11 )
 Description.part1.rar 120,00 Kb

Часть вторая

Присоединённый файл ( Кол-во скачиваний: 10 )
 Description.part2.rar 38,57 Kb

Кладу более новую версию описания  

Присоединённый файл ( Кол-во скачиваний: 6 )
 Description.rar 19,63 Kb

Немного переключился с разработки к более углублённому анализу существующих распределённых сред - нужно написать серьёзную статью с разбором всех имеющихся систем и технологий, а также с определением целей Octopus. Разбираю CORBA, Globe, Amoeba и другие... Если у кого есть материалы по сравнительному анализу распределенных систем, был бы рад ими воспользоваться.    Спасибо. Энтузиасты, не спите - проявляйте интерес хотя бы время от времени, а то одиноко как-то всё самому да самому...   

Идея очень интересная и хотел бы поучаствовать, но  пока занят другим проектом (да и не готов еше на такой уровень)
Однако с удовольствием послежу за развитием.  

Три месяца работы и одни концепты? Над проектом работает один человек? Нереально.

Я вообще поражён Вашей инициативой разработки своей ОС (меня тоже посещали мысли о том что не плохо бы иметь объектную ОС, я даже для неё название придумал ООС)

Что мне нравиться:

Это грамотно. Мне очень нравиться.

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

Обратную нативацию тоже хотелось бы предусмотреть. Например для драйверов и пр.


Я думаю самое ценное для автора это критика. И вот мои критические замечания.

1) Почему не рассматривается ОЗУ, Файловая система и пр. как объекты?
2) Мне не нравиться единое идентификационное пространство. Каждый объект должен быть независим и в тоже время иметь доступ к специальным объектам, которые будут предоставлять ему коммуникацию в окружающую среду по определённым интерфейсам (которые скажем можно заменить моками, например для тестирования или для особых прикладных нужд). Более того, единое идентификационное простренство предусматривает некую монолитность, что уменьшает распределённость. Для решения этой проблеммы необходимо разработать систему специальных идентификационных объектов (верней интерфейсов), притом предоставить несколько вариантов, чтобы пользователь-объект мог выбрать, что ему больше подходит.
3) Необходимо рассмотреть объект-носитель для некоторых видов объектов (например файловая система - это объект-носитель файла). Необходимо предоставить возможность существования нескольких интерфейсов для объектов носителей, а ещё лучше чтобы их можно было расширять по усмотрению пользователя. В этом случае на первых порах разработки можно приспособить существующие файловые системы с ограниченным функционалом системы, а потом расширять или заменять навороченными новыми файловыми системами или верней уже системами-носителями тех или иных видов объектов (например носитель личности человека!!!  )
4)  то же не нравиться. Необходимо разработать систему интерфейсов (ну и потом написать какую-нибудь их реализацию), предоставляющую различные ресурсы различным видам объектов. И уже на основании данной догматики, ПЫТАТЬСЯ разработать единые интерфейсы ввода-вывода, командно-консольные интерфейсы, графические интерфейсы или чё-нибудь новое (например экспертные речевые системы)

У меня были ещё замечания но я чёт их забыл, потом вспомню, напишу.

Какие будут Ваши коментарии по поводу моей критики?

ЗЫ. Изначально-стратегически необходимо поймать два зайца: архитектура должна предоставлять гибкие возможности для автономности объектов, и предоставлять гибкие возможности для объединения большого количества разлиных автономных объектов на разлиных носителях с различными каналами взаимодействия и с различными принцыпами идентификауии (не следует изначально полагаться на мгновенность доступа - если сервер будет находиться на Марсе, то за секунду и даже за минуту сообщение туда не передашь).

ЗЫ2. И не слушайте АСМистов: реализовать такую систему на АСМе, всеравно, что перекопать всю тайгу лопатой.

Это сообщение отредактировал(а) pompei - 21.11.2007, 09:23

Спасибо за замечательный отзыв! 

Постараюсь ответить на ваши замечания насколько смогу:

1) Файловой системы не подразумевается как таковой – предполагается объектно-ориентированное хранилище объектов, интегрированное с виртуальной памятью. Объект может быть объявлен как persistent, т.е. сохраняться после окончания сеанса пользователя (т.е. и при выключении хоста).
2) Интернет является примером единого идентификационного пространства (IP-адреса). При этом он не теряет своей децентрализованности и масштабируемости. Смысл идентификаторов – эффективно локализировать конкретный объект в сети (по сути, он является сетевым адресом объекта).
3) Да, это и подразумевается.
4) Цитируемый текст не противоречит вашим замечаниям. Дело ещё в том, что выложенные мною документы не могут дать полноценного представления об архитектуре. Многие её аспекты до сих пор уточняются… однако есть существенный прогресс – работа не прекращается.
Сейчас пытаюсь провести многосторонний анализ всех существующих систем подобного рода.  Читаю материалы по зрелым системам CORBA, COM+, Java RMI, а также по разрабатываемым Globe, Chord, OceanSpace, EROS, Cosm и другим. В ближайшем времени напишу статью, в аналитической части которой ожидается критический разбор существующих систем, а синтетической – парадигма и  ключевые идеи разрабатываемой архитектуры. 

Выкладываю обещанный обзор существующих распределённых систем. Приступаю к описанию целей проекта.

Присоединённый файл ( Кол-во скачиваний: 25 )
 _____________________________________________________________________.pdf.zip 117,86 Kb

Неужели никому не интересна моя тематика? 

Что поделаешь, такова судьба пишущих ядра . Линус Товальдс тоже в одиночку начинал и надо отдать ему должное, в демагогию не ударялся, а просто представил общественности почти готовое ядро. Правда ему было легче, т.к. для получения полноценной ОС ему достаточно было лишь откомпилить самые необходимые приложение (вроде bash или vi), которые распространялись в виде исходников. И операционка готова! Вам же будет сложнее, так как никакого мат. обеспечения под Вашу ОС пока ещё нет...
Вам бы было легче, если бы вы реализовывали не полноценную ось, а какое-нибудь объектно-ориентированное расширение для одной из существующих осей. Тогда если оно действительно было такое удачное, то можно было бы существующие проекты постепенно переносить на него. А так вы один...
Все вышеперечисленное - мое субъективное ИМХО. Спорить не буду.

P.S. Извиняюсь, если вдруг допустил какие ошибки в именах собственных. Не линуксоид я. Просто хотел разжевать чужой опыт.

чем-то напоминает
http://rus-os.narod.ru/
 

Улыбнуло, гугл умрет от зависти   

Линус Торвальдс писал реализацию Unix на 386-том процессоре. В его распоряжении был готовый каркас архитектуры и системные вызовы. А начинал он с улучшения Minix. Я же не хочу писать очередной клон Unix, а пытаюсь понять современные нужды и выработать основные черты НОВОЙ архитектуры (ни в коей мере не пытаюсь себя сравнивать с Торвальдцом - мне до него в области системного программирования и знания архитектуры x86 далеко). Короче, я к тому клоню, что прежде чем что-то кодировать нужно знать, что именно… а вот с этим пока и проблема. Сейчас я пока занят статьёй, в которой формулирую требования к будущей системе с учётом всего того, что есть и что нужно (на мой субъективный взгляд). 

Почему нельзя для распределенных вычислений использовать существующие операционные системы?

Добавлено через 56 секунд
Прежде чем дергаться такое писать, нужно хотя-бы одну распределенную программу написать, ну хотя-бы многопоточную))

концептуальнык конфликт. осьминог (т.е. окотпус) является централизованной системой.
в центре - мозг. ноги идут радиально.

Это название возможно отражает некоторые нестыковки, которые пойдут далее.


рекомендую изучить существующие решения, которые вы не затронули.
вы разделили на т.н. middleware не то, что является концептуально middleware.
напр. т.к. IPC существует и штатное, к IPC нельзя относиться как к механизму отдельному от OS.
кроме того вы не затронули вообще существующие системы распределенных вычислений, как то анализ 

• 1. High Performance Computing
• 2. High Throughput Computing + Voluntary Computing
• 4. Group Communication/Process migration

Вы также не определились какую из этих задач вы пытаетесь решать/решить.
Заметьте, что решение распределенной ос не имеет смысла для решения пунктa 2.

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

Еще, сама сфера распараллеливания вычислений не совсем понятна с т.з. соотношений 
выгоды/вклада ведь:

• не каждая вычислительно сложная задача параллелизуема .. как бы сказать can be parallelized.
• не каждая параллелизированная задача масштабируема
• не каждое масштабируемое решение масштабируется до бесконечности.

т.е. можно сделать расчет, что начиная с масштаба М есть выгода, а до масштаба М дойти нельзя.

И еще о выгоде: сегодня ВСЕ серьезные проекты open-source находятся под крылом фондов индустрии. Фирмы как IBM, Microsoft, Sun, HP, SGI и т.д. вкладывают человек-месяцы в разработки таких вещей как:

• ядро линукс
• драйвера
• разработки больших приложений и библиотек.

т.е. нужны "фонды" и работники на полную ставку.
Если вы хотите привести пример линукс, как пример "коллоборативной работы добровольцев", то поинтересуйтесь поглубже, что такое kernel janitors, и т.д.
Я хочу сказать, что парадигма открытого ПО больше помогает корпорациям в создании базы тестировщиков, чем увеличивает темп разработки. И еще, заметьте что самые продуктивные программисты будут работать за деньги, как это и происходит с линуксом.


У вас есть такие фонды ?
Скажем так: в России только ГазПрому под силу такой проект ;-)


В заключение, я не могу не согласиться с Lazin-ым: 
вам пока не хватает, ИМХО, базовых и практических знаний в этой сфере.


Почитайте и поковыряйтесь, или докажите что мы ошибаемся.

Удачи.

Добавлено через 9 минут и 48 секунд
хотя бы это:

да, только это решается именно в сфере HTC, a не на уровне ОС.
и уже довольно не плохо решается.

можете пояснить это предложение ? 
слишком "много букв"....
то ли мне кажется что доступ к данным не представляет собой ... никакой проблемы посредством существующих средств, то ли непонятно где эти данные, и почему подкачать автоматом библиотеку поддержки этого формата не решит проблемы.
т.е. если они у пользователя на компутере, то ... куда мы их распределять будем ? а они конфиденциальны ?
прямо напрашивается нехорошее слово.

или вот пример:

и:

не стыкуется, возможно т.е. я не понимаю что именно вы видите главным в простоте и красоте юниксов.
Я напр. как раз вижу в файловой абстракции + базовых операциях ( read/write/exec/fork/ioctl и т.д. )

ИМХО: простота и красота в файловой абстракции , которая и является недостатком вследствии ее ограниченности.

Можно, но не очень удобно. Хотелось бы проще это делать. Но я бы поставил упор на удобстве использования ресурсов других компьютеров, а также на поиске информации.



Распределённую программу я писал только одну, многопоточных – много. Но вы правы, у меня недостаточно опыта в области распределённого программирования. Но можно я хотя бы попробую?   



Я с вами согласен – старое название не совсем подходит – оно подвернулось мне, когда я не уделял должного внимания распределению и децентрализации. 

bilbobagginz: Да, я не особо рассчитываю на результат (тайком конечно надеюсь на удачу, на то, что напишу ядро, и вокруг него создастся круг единомышленников, которые будут его оборачивать пользовательскими слоями, но, конечно же, понимаю маловероятность такого исхода). Для меня это скорее долгоиграющее хобби…



Полностью с вами согласен.



Да, файловая парадигма очень красива, мощна и вместе с тем ограничена (например, в сравнении с ОО парадигмой). 

Ну что тут скажешь... удачи, может что-то из этого и получиться, библиотека какая-нибудь, или программа...
PS
Кстати, чем плох для этих целей erlang?

Я не знаю, что это такое - сейчас открою, почитаю.

кхм... хотел бы услышать пример ограниченности парадигмы "всё есмь файл" в контексте нашей дискуссии, т.е. в контексте оперативной системы... распределенной оперативной системы.

Ярким примером того является Plan 9 – в этой системе почти всё есть файл, включая даже процессы. Системные вызовы, соответственно, в основном сводятся к открытию, чтению, записи и закрытию файла. В системе Plan 9, как ни в какой другой и проявляется слабость файлового представления сущностей. Эту слабость иллюстрирует существование в ней системных вызовов, отличных от вышеперечисленных, семантически не вписывающихся в файловую парадигму (например, вызовы управления разделяемой памятью). Кроме того, по сути, устройствами управляют при помощи текстовых команд, читая и записывая в соответствующие им файлы текстовые строки. Другими словами команды read и write в данном случае служат только шлюзом, направляющим сложные команды управление в ту либо иную сущность, а вся логика управления прячется в тексте команды.

это описание механизма и динамики.

Можете указать в чём ограниченность ?
Я пока еще не врубил.

Добавлено через 4 минуты и 19 секунд

я не понимаю проблематичности. всё это реализуется на основе read/write/open/close/ioctl

думаю что кроме базовых вызовов должны быть более сложные вызовы делающие сложные дейтвия но имеющие простое название.

Смотрите, с моей т.з. ограниченность это существование какого-то предела, который не переступить, или существование какого-то региона/сектора действий, до которого ужасно сложно дойти.

Это всё (включая фичи из спецификации) реализуются в пользовательском окружении, т.е. можно на любой OS. Современные ОС имеют тенденцию выносить всё из ядра в user-space. Не только ради изоляции (стабильности), но и просто потому, что гибко, можно заменять и добавлять новые фичи не тревожа при этом ядро.

Вывод: стоит реализовать идеи на существующих ОС, к примеру Linux. Затем оценить необходимый функционал со стороны ядра ОС, что бы оценить целесообразность новой ОС. Если потребность в ней всё таки останется, то включиться в модификацию Minix 3, благо не плохая микроядерная ось.


P.S. ой, повторяюсь за bilbobagginz 

Опыт показывает, что наш диалог на форуме превращается в бесполезные  словесные препирательства, причём каждый остаётся при своём мнении. Ребята, нет сил и времени тратить на демагогию (у меня ещё учёба и 2 работы  ). Если у вас есть конструктивные идеи, либо предложения касательно моей работы - буду рад поучаствовать в дискуссии.

Видимо у нас разные ожидаемые результаты и процесс самой дискуссии.

Мы всего лишь хотим понять ваши идеи, и продуктивно поспорить, т.е. поднять вопросы, которые у нас поднимают бровь.

Если вы пришли сюда с идеей: "вот так я хочу! и всё.", и не можете ответить на довольно базовые вопросы, то как вы думаете потенциальный участник вашего проекта на это всё станет смотреть ?

Вы не просто можете, вы должны свои позиции уметь объяснять членом раздельно.
Мы же вас не про то как рыбу засаливать спрашиваем.

После вашего последнего поста уже склоняюсь к анализу Rickert-a.
Кроме того, вы тут упомянули учебу, 2 работы. 
С т.з. логистики - нет шанса.

3/4 статьи - кроме переработанного обзора распределённых систем есть мысли касательно улучшения поиска информации в Интернете (с картинками   )

Присоединённый файл ( Кол-во скачиваний: 17 )
 _______________________________________________________________________.part1.rar 120,00 Kb

2-я часть архива

Присоединённый файл ( Кол-во скачиваний: 11 )
 _______________________________________________________________________.part2.rar 106,05 Kb

Закончил писать вводную статью. Кладу её целиком. Жду ваших отзывов!

Присоединённый файл ( Кол-во скачиваний: 8 )
 _______________________________________________________________________.part1.rar 120,00 Kb

(вторая часть архива)

Присоединённый файл ( Кол-во скачиваний: 5 )
 _______________________________________________________________________.part2.rar 120,00 Kb

(третья часть архива)

Присоединённый файл ( Кол-во скачиваний: 6 )
 _______________________________________________________________________.part3.rar 43,45 Kb

Высылаю начало статьи, описывающей базовую архитектуру. Также прилагаю часть текста, который скоро войдет в эту статью (он отрывается от текущей нити изложения).

Присоединённый файл ( Кол-во скачиваний: 4 )
 ____.zip 281,66 Kb

Последняя редакция документа (существенно дополненная). Эххх... похоже не встретить мне единомышленников...

Присоединённый файл ( Кол-во скачиваний: 18 )
 ________________.pdf 655,53 Kb

пожалуйста давайте латинские названия именам файлов, или пользуйтесь utf8.
качаю последний документ. завтра посмотрю.

Внятное и простое введение в мои архитектурные концепты в следующих тезисах:

1. Хост – всё, что имеет микропроцессор и выход в Интернет.
2. Система – множество всех хостов.
3. Хосты содержат объекты (одиночное наследование классов, множественное наследование интерфейсов).
4. Типы это объекты, описывающие классы.
5. Объекты могут взаимодействовать друг с другом только посредством синхронного вызова метода.
6. Компоненты – объекты, методы которых могут быть вызваны объектом на другом хосте.
7. Компоненты есть долгоживущие объекты (сохраняются на энергонезависимых устройствах хранения).
8. Типы являются компонентами.
9. Каждому компоненту соответствует глобально уникальный идентификатор (GUID).
10. При копировании компонента новая копия получает новый GUID, а при перемещении GUID сохраняется.
11. Некоторые компоненты являются реплицируемыми и обладают уникальным идентификатором реплики (RUID).
12. При копировании и перемещении реплицируемого компонента его RUID сохраняется.
13. Типы константны и являются реплицируемыми компонентами.
14. Система поддерживает глобальный поиск GUID компонентов по Prolog-подобным запросам, оперирующим отношением наследования, RUID и другой информацией.
15. Интерфейс – компонент, описывающий набор методов.
16. Интерфейсы константны и являются реплицируемыми компонентами.
17. Существуют только интерфейсные ссылки, объектных ссылок не бывает.
18. Интерфейсная ссылка на компонент может быть получена только через системный вызов, берущий в качестве аргумента GUID требуемого компонента и ссылку на требуемый интерфейс.
19. Систему пронизывает множество потоков.
20. Объект, у которого внутри нестатического метода выполняется какой-то поток, считается запертым.
21. Внутри нестатического метода объекта может находиться не более одного потока.
22. Поток может вызывать нестатический метод с ожиданием и без.
23. При вызове с ожиданием в случае запертого объекта вызывающий поток будет блокирован, ожидая отпирания.
24. При вызове без ожидания в случае запертого объекта вызывающий поток сгенерирует соответствующее исключение.
25. Ссылка на компонент может быть получена только при наличии достаточных полномочий, в противном случае будет сгенерировано исключение.
26. В системе существуют учётные записи – компоненты, описывающие пользователей системы (люди или программы).
27. Право есть возможность получения ссылки заданного интерфейса на заданный компонент.
28. Каждый компонент ассоциирован с учётной записью – его хозяином.
29. Компонент имеет все права на компонент с тем же хозяином.
30. Назначение права есть триада: [GUID компонента, RUID интерфейса, флаг доступа (разрешён/запрещён)].
31. На хосте существуют группы – объекты, описывающие набор назначений прав на компоненты данного хоста.
32. Учётная запись входит в одну или несколько групп, определяющих набор её прав (при отсутствии назначения или при наличии хотя бы одного запрещающего назначения – право отсутствует).
33. Компонент имеет права своего хозяина.

Кого заинтересует зову на форум: Совместная разработка новой ОС