| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Идеология проекта | |||
|
|||
 Про королей (то бишь ядро) и капусту (пользовательские приложения и данные)  |
| Автор | Отправлено |
| HandleX |
|
||
Сообщений - 18 |
У-у-у, как всё запущено В смысле, запуск (старт) хороший — с нуля Про интерфейс. Даже не столько про интерфейс, сколько про Концепцию. Очень хорошо, что нет файловой системы. Очень хорошо, что объектно-ориентированная OS. Давайте позанудствем и рассмотрим, что мы имеем в любом компьютере. А в любом компьютере мы имеем процессор, оперативную память, и устройства ввода вывода на шинах. Причём шина — тоже устройство ввода-вывода, налицо древовидная (иерархическая) структура. И имеем операционную систему, которая пытается рулить всем этим хозяйством. В операционной системе часто выделяют защищённое ядро, которое занимается планированием задач и контролем доступа к разделяемым ресурсам. На этом нижнем уровне неважно, как реализовано ядро — будь то чистый ассемблер, С или С++ или ещё там что-либо экстравагантное. А теперь некоторые мысли по поводу скорости, надёжности, и концепции, причём с уклоном под архитектуру IA32, поскольку я с ней наиболее хорошо знаком. 1. Виртуальная память. Очень много дырок в безопасности связаны с переполнением буфера и срывом стека, что является следствием невозможности установить на страницу «запрет на исполнение» из-за дани моде на flat-модель. Может стоить на неё забить и выделять приложению несколько flat-областей с необходимой защитой? К примеру на стек, код и данные? Остаётся вопрос, насколько красиво реализована работа с межсегментными указателями самим процессором и компилятором Open Watcom. Говорят, в новых версиях процессоров Intel и AMD введут дополнительный флаг защиты на страницу памяти. Но… не скоро мы увидим эти процессоры в домашнем «пылесосе» 2. Разделяемая память как очень быстрый механизм IPC (вкупе с сообщениями) должна использоваться очень активно. 3. В настоящий момент довлеет использование 2-х колец (0 и 3) в современных защищённых OS. В нулевом ядро, в третьем пользователи Может стоит подумать и вынести некоторые подсистемы (к примеру, IO manager, VM Manager, Sheduler) в различные кольца с различным уровнем привилегий (для пущей безопасности), или забить на это дело и пойти проторенным путём… Но гложет меня мысль, что светлые головы Intel не для того придумали четыре различных уровня привилегий, чтобы все на них забивали 4. Предусмотреть механизм «рекреации» подсистем по открытым на них дескрипторам… К примеру, глюкнул драйвер видео. В винде — синий экран. А у нас пусть OS его перезапустит, если опять глюкнул, то запустит Generic VGA, дабы пользователь смог корректно закрыться. Огромный плюс — если разработчики драйверов почувствуют весь вкус и комфорт (нет бесконечных отладочных перезагрузок), то сильно ускорится разработка драйверов под новую ось. На этом же принципе можно заложить отказоустойчивость: к примеру, глюкнул сетевой интерфейс — запустить резервный, да так, чтобы службыприложения это даже «не заметили». Важный момент — организовать вызов системных служб из пользовательского режима таким образом, чтобы всегда имелась возможность сообщить потоку, что системный вызов не удался. Тогда появится возможность использования «OS Magic» для отмены системного вызова, если он по каким-то причинам сильно затянулся и пользовательский поток «подвис». Знаете, как это выглядит при зависании приложения в WinNT и выше? Только «Убить», но и то не при системном вызове А у нас, если есть в наличии подвисший системный вызов, дать явную возможность пользователю отменить его. 5. Глобальный отказ от файловой системы вообще (3OS Team уже говорил об этом). Ведь на самом деле это память, только немного медленная и с другим методом адресации Раз уж у нас объектная модель, то пусть будут объекты «до конца», ведь OOПодход активно применяется для выделения «сущностей» в оперативной памяти. Так пусть тогда всё то, что лежит на долговременных носителях, будет «кормом» для объектов в ОЗУ, причём грех к этому «корму» не применить объектный подход 6. Пусть пользователь даже «не знает», где физически хранятся его данные. У OS должно быть объектно-ориентированное хранилище постоянных данных, некий PDO (Persistent Data Object) менеджер. Древовидная структура, мощный механизм индексирования, кэширования и проч. Не только горизонтальные, но и вертикальные запросы (по дереву). Очень похоже на ООБД — объектно-ориентированные базы данных. Транзакции… Хм, если всё это будет так, как мечтается, то Oracle отдыхает Вообще, это должен быть «стержневой компонент» новой OS. К примеру, «папка» в новой OS по сути будет просто набором именованных указателей на PDO, что-то вроде индекса. А может и не будет «папок» в привычном понимании… 7. Активное использование в PDO «свойств по умолчанию» и «наследуемых свойств» (от контейнеров верхнего уровня). Т.е. если значение свойства конкретного объекта не указано, но оно может быть применимо к этому объекту, то при попытке его чтения будет выдано наследуемое свойство от контейнеров (если такие есть), или значение по умолчанию. Повышается компактность и красота реализации чего угодно, яркий пример — списки контроля доступа к объекту. Кстати, у защищённых объектов появляется некая часть свойств и логики, управляемая только подсистемой защиты. 8. Для любого объекта должен быть некий «браузер», который красиво и функционально покажет его свойства пользователю и позволит редактировать их. Общая тенденция — данные как в ОЗУ, так и в PDO должны хранится максимально компактно, поэтому ASCII и XML отдыхают. Незачем _хранить_ данные в человеко-читаемом виде (причём в уродливо-читаемом ), поскольку браузер обекта покажет их гораздо качественне, осмысленнее и не нарушит бизнес-логику. Если надо для коммуникации с другими системами, то пожалуйста — хотите в XML (туда смогут быть отконвертированы любые PDO), хотите в ASCII («древовидность» будет хромать). 9. Очень было бы чудесно, если бы пользовательские приложения были на самом деле PDO с интегрированной в него бизнес-логикой, желательно в исходных кодах При первом запуске приложение компилируется (по умолчанию — с учётом конкретной архитектуры и железа). Если вы чайник со свистком, то вам никогда не понадобиться изменять свойства такого PDO, вы будет просто наслаждаться результатами его работы. А если вы программер, то редактирование такого PDO выльется в запуск среды разработки. Ненужно хранить исходный код в ASCII — это могут быть метаданные компилятора. Если есть его «раскрученный» исполняемый экземпляр в памяти, можно запустить отладчик. Побольше понавтыкать палок в колёса товарисчам, которые хотят распространять приложения без исходников Помощь (справочная информация) для пользователя при работе с приложением тоже обязательно должна хранится там же, в PDO. Системные службы — те же PDO, только запущенные в нужное время неким планировщиком задач, типа services.exe в NT. Вообще, система в выключенном состоянии представляет собой набор PDO на долговременных носителях. В загруженном состоянии то же самое, только вся бизнес-логика раскручена и активно взаимодействует между собой 10. Как можно меньше плодить «новых сущностей». Основной источник «новых сущностей» — поддержка различных интерфейсов (к примеру, сетевого обмена) и файловых форматов «вражеских» систем Ну вот, закругляюсь, остальные могут добавить... Может всё это несколько сумбурно, тогда поправьте меня. Просто это крик души, то, что наболело за десятки лет использования компьютеров. |
||
| Наверх |
|
| AlexeyASugonyaev |
|
||
|
Зарегистрирован: Tuesday 18.11.2003 06:36 Местоположение: Челябинская обл., г.Карталы Сообщений - 68 |
Про все говорить не буду но некотрые темы реально близки мне как разработчику именно части ядра 3ОС. По поводу адресного пространоства, соверешнно верно Intel не зря применила механизм страниц и 4 !!! а не 2 (как обычно бывает при использовнаии страничной модели памяти как основной). В 3ОС я старательно лобирую сегментно-страничную модель памяти (несмотря на то что это потом затруднит портирование на другие платформы), есть некоторые нюансы заложенные заранее в ядро 3ОС на высоком уровне могущие снизить расходы на "порт". Насчет указателей и компиляторов - это конечно больная тема, но не столько что бы ее невозможно было преодалеть. Т.е. на мой взгляд эта задача решаемая и проходящие эксперемнты над ядром весьма неплохо об этом свидетельствуют. Разделяемая память сама по себе мало что значит а при использовании в ЛОБ является при этом неплохой дыркой в защите ОС. Я не говорю ято в 3ОС не будет разделяемой памяти, будет... но в определенном ООП ракурсе. Как такового в Desktop версии системы классический механизм IPC будет присутсвовать только как этап при работе с удаленной машиной. Для других будет использовани более прогрессивный и бытсрый (на мой взгляд) вызревший в группе 3ОС очень прогрессивный механизм IPC - в 3ОС называемый как "УД - удаленный доступ к объекту". По поводу ОО ядра, тут наши с Вами взгляды несколько расходятся, потому как не может такой проект как ООС быть на уровне ядра просто завернут в ОО оболчки для вызовов. Это и несерьезно, да и идет в разрез с парадигмой УД. Так что ядро 3ОС пишется на C++ от и до. Про механизм рекреации уже говорили в форуме, использовать его можно и нужно, но при условии, что существует механизм позволяющий отделить сбои аппартуры от сбоев программных (происходящих по вине самих программистов, разработчиков сбоящих сервисов и драйверов). В противном случае работа системы будет напоминать работу Spirit на Марсе - 140 перезагрузок (рекреаций) между сеансами выхода на связь. ж-)) Ну и конечно Вам нужно попасть в команду 3ОС, если вы разделяете наши взгляды так плотно. | ||
| Наверх |
|
| Alexey Revin |
|
||
 
Местоположение: Россия. г.Челябинск Сообщений - 43 |
А про быстродействие вы так и не заикнулись. 
|
||
| Наверх |
|
| Roman I Khimov |
|
||
 Местоположение: Россия, Санкт-Петербург Сообщений - 178 |
Читать такие посты приятно, огромное спасибо уже за это одно! HandleX писал(а): ... Остаётся вопрос, насколько красиво реализована работа с межсегментными указателями самим процессором и компилятором Open Watcom. Сегментация - больная тема. Процессоры-то ее поддерживают хорошо, а вот компиляторы, операционные системы и приложения - никак. Что есть плохо, и что надо решать. Сегментно-страничная память, как и сказал Алексей Сугоняев, для нас есть норма. HandleX писал(а): ... Но гложет меня мысль, что светлые головы Intel не для того придумали четыре различных уровня привилегий, чтобы все на них забивали Однозначно. Опять-таки это уже заложено в идеи реализации 3ОС на платформе x86! HandleX писал(а): ... Предусмотреть механизм «рекреации» подсистем по открытым на них дескрипторам… Кстати, есть подозрение, что в этом помогут те самые 4 кольца, а не два. HandleX писал(а): ... Глобальный отказ от файловой системы вообще (3OS Team уже говорил об этом). Ведь на самом деле это память, только немного медленная и с другим методом адресации Черт побери, но это моя идея! Сеть - хранилище и исполнялище, если есть расшаренные сервисы. Диск - хранилище и кэш сетевых объектов. ОЗУ - кэш диска. Вот и все. Но это пока не является официальной концепцией проекта, так как есть в этом и спорные моменты. HandleX писал(а): ... А может и не будет «папок» в привычном понимании… Не будет.  HandleX писал(а): ... Для любого объекта должен быть некий «браузер», который красиво и функционально покажет его свойства пользователю и позволит редактировать их. Общая тенденция — данные как в ОЗУ, так и в PDO должны хранится максимально компактно, поэтому ASCII и XML отдыхают. Однозначно. HandleX писал(а): ... Ну вот, закругляюсь, остальные могут добавить... Может всё это несколько сумбурно, тогда поправьте меня. Просто это крик души, то, что наболело за десятки лет использования компьютеров. Ты знаешь, это просто поражает - очень многое прямо повторяет наши идеи, кое-что косвенно... Готов ли ты влиться в команду разработчиков? Греби и улыбайся!
|
||
| Наверх |
|
Модераторы: Roman I Khimov, netwizard. |
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |