| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Идеология проекта | |||
|
|||
 Зачем?Перейти к странице Предыдущая -1-2-3-4-5-6-7-8-9-10-11-12-13 Следующая |
| Автор | Отправлено |
| Vadim Ushakov |
|
||
Местоположение: Россия, Красноярск Сообщений - 35 |
Некоторое время назад я писал: Vadim Ushakov писал(а): ... Поскольку Roman I Khimov с того времени никаких реплик в форум не подавал, я пока ничего ему писать не буду. Может ему "до лампочки" все мои соображения, или просто некогда. Попытаюсь кратко(:)) изложить, что я имел ввиду, говоря о специальной поддержке со стороны ядра. Почему для функционирования кодеков нужно специально на это рассчитанное ядро, я вам на e-mail напишу через пару дней, если вы не против. Со времен Юникс во главу угла ставятся две сущности: процессы, которые работают от имени конкретного пользователя (исполняют его волю), и плоские файлы, которые обрабатываются этими процессами. Эти файлы являются субъектами действий пользователя. Одна из концепций Юникс, которую сразу объясняют всем изучающим эту систему: процесс - это то, что что-то делает. Что он может делать? Практически все, лишь бы не трогал файлы, создатель которых запретил доступ к ним. Однако в рамках концепции ОООС, и субъект и тот, кто его обрабатывает, описываются как "объекты", а не как файлы и процессы. Следовательно, привычные нам абстракции - процесс, поток, контекст, права доступа к ресурсу - обозначают уже совсем не то, что в Юникс. (К сожалению, большинство не-Юникс систем написано "по мотивам" Юникс.) Такое понятие, как принадлежность процесса пользователю вообще теряет всякий смысл. Ведь объекты "отвязаны" от конкретных процессов. Поясню свою мысль. Во всех существующих ОС определяется понятие пользователя, который имеет определенные привелегии для доступа к ресурсам. Для системы пользователь - это абстракция - просто запись в базе данных менеджера безопасности. Волю пользователя исполняют некие активные сущности, которые наделяются привелегиями этого пользователя; считается что действия пользователя и действия этих "агентов" - это одно и тоже. В большинстве систем в качестве этих активных сущностей используются процессы. Для системы процесс - это конкретизация абстракции "пользователь". ОО-системы отказались от этого подхода. Здесь волю пользователя представляют АКТИВНЫЕ ОБЪЕКТЫ - они и должны обладать привелегиями. Удивительно, но разработчики ОО-систем не акцентируют внимание на том, что теперь процесс - это всего лишь способ уберечь систему от зависания, если в каком-нибудь методе содержится глючный код. Они направили острие критики на понятие о файле и забыли о второй "священной корове" Юникса - процессе. Между тем в ОО-системах процесс лишен своей "сакральной" сути и имеет сугубо практическое значение: процесс - это способ изоляции кода в отдельном пространстве адресов с целью повышения устойчивости системы к программным ошибкам. В большинстве ядер, даже в микроядрах (не говоря уже о монолитных) неявно подразумевается именно юникс-процесс. Если мы используем такое ядро, то становимся зависимы от "старой" идеологии, против которой так настойчиво боремся. Именно поэтому я предлагаю (уже в который раз) использовать экзоядро, как оно было спроектировано Энглером и механизм Scheduler Activations. Экзоядро не навязывает своей идеологии - у него ее практически нет - мы можем сконцентрировать всю "идеологическую" функциональность в runtime-библиотеке. Я полагаю, что правильное решение проблемы привелегий и прав доступа к объектам позволит переосмыслить такие понятия как "поток", "контекст исполнения", "владение ресурсом". У меня есть некоторые идеи, однако они еще слишком сыры, чтобы я смог внятно изложить их в письменном виде. Конечно проектировщики 3ОС могут игнорировать эту проблему, как это сделано в Native Oberon. Однако Native Oberon была исследовательским проектом, 3ОС же претедует на нечто большее... [ Редактирование Thursday 10.02.2005 14:19 ] |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Vadim Ushakov писал(а): ... Stdout он просто есть. Ни кто не заставляет на него что-то посылать. Я вообще не понял, что ты хотел сказать - может ты не знаешь, что такое POSIX)?
AlexanderK писал(а): ... Мы здесь копья ломаем: писать собственное ядро или не писать. А решение оказывается простое - хотел бы я посмотреть, как объекты, выстроившись в колонну, дружно отправляются на stdout. А лучше на stderr.Любая ОС предоставляет POSIX, этого достатоточно для реализации чего угодно. |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
czarker писал(а): ... Я говорю не осоздании POSIX ОС, а о создании 3ОС состемы на основе POSIX других систем. Система может использовать POSIX в качестве ядра.
Не надо! Либо мы имеем UNIX-основную ОС, и тогда логичней нести бремя предельной совместимости, либо мы имеем UNIX-несовместимую ОС, и тогда реализация через POSIX или его части - зло. |
||
| Наверх |
|
| czarker |
|
||
Местоположение: Москва, т.д. Сообщений - 48 |
Vadim Ushakov Vadim Ushakov писал(а): ... Я знаю. Мне просто интересно, какую группу объектов Вы туда посылаете. Сама суть stdout и stdin (ну и stderr в некотором смысле) заключается в том, что через него передаются не объекты, а потоки. Иначе в pipe не было бы смысла. czarker писал(а): ... На stderr я обычно посылаю все те нехорошие слова, которые программа говорит пользователю, не умеющему с ней работать Кстати, а какие данные Вы на stderr посылаете?  . Vadim Ushakov писал(а): ... Имелись в виду драйверы устройств. Как это сделано в Linux.Если для .NET runtime нужна серьезная поддержка со стороны каких-либо драйверов, то толкать его в 0-е кольцо нет смысла, независимо от того, используем ли мы модульный подход или "микроядерный" (в том смысле, о котором я писал ранее). Vadim Ushakov писал(а): ... А иначе-то как? Не утянягивать же в ядро все объекты... Если мы берем за основу .NET, то логично вынести всю ее нетривиальную функциональность в отдельный процесс, и пусть "верхнеуровневые" объекты обращаются к ней через IPC, а она, в свою очередь, обращается с запросами к "нижнеуровневым" объектам. P.S.: Во-первых, не надо ссылаться на документацию 3ОС - она официально признана устаревшей; во-вторых: Vadim Ushakov писал(а): ... Не противоречит. Драйвер файловой системы должен находиться на одном уровне с драйверами устройств. Между прочим, слова Czarker о драйверах, работающих прямо в ядре, противоречат его же высказыванию: czarker писал(а): ... Или вы считаете, что драйверы периферийных устройств в прогрессивной объектно-ориентированной системе должны работать ниже файловой системы? Кстати, тогда речь шла о предыдущей концепции 3ОС, которая радикально отличается от новой. AlexanderK POSIX - это Portable Operating System Interface. Описание интерфейса системы. Технологический прогресс пока ещё не позволяет мануалы в качестве ядра ОС использовать.  [ Редактирование Thursday 10.02.2005 16:24 ] Но это всё, конечно, моё сугубо личное мнение. |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
czarker писал(а): ... Причём здесь мануалы? Это спецификация, реализуемая всеми мейнстримными ОС. Что-то ты не догоняешь POSIX - это Portable Operating System Interface. Описание интерфейса системы. Технологический прогресс пока ещё не позволяет мануалы в качестве ядра ОС использовать. 
|
||
| Наверх |
|
| Vadim Ushakov |
|
||
|
Местоположение: Россия, Красноярск Сообщений - 35 |
"@#$%^&*!!!" - воскликнул я, прочитав новые сообщения на форуме. Czarker, я от вас ждал чего-то большего, чем мелких придирок к фразам, вырванным из контекста. Вы бы еще про неправильно расставленные запятые рассказали. Так уж и быть, я отвечу на все ваши придирки, но давайте впредь заниматься конструктивной критикой, а не писать комментарии на комментарии на комментарии друг друга. Если вам не интересно то, о чем я писал, так и скажите. czarker писал(а): ... Я хотел сказать, что POSIX категорически не подходит для чего бы то ни было объектного. По поводу объектов, марширующих по stdout - это была шутка (возможно неудачная), если вы не поняли. Мне просто интересно, какую группу объектов Вы туда посылаете. czarker писал(а): ... Если под ядром здесь имелся код, работающий в 0-м кольце, то я КАТЕГОРИЧЕСКИ ПРОТИВ размещения в этом "ядре" каких-либо объектов. В 0-м кольце "сидит" только менеджер аппаратных ресурсов: страниц физицеской памяти, портов, прерываний, квантов процессора. А иначе-то как? Не утянягивать же в ядро все объекты... czarker писал(а): ... Я не ссылался на какую-либо документацию и не цитировал ее - даже в мыслях такого не было. не надо ссылаться на документацию 3ОС - она официально признана устаревшей czarker писал(а): ... Тем не менее, тогда вы были против модульного ядра Linux, а теперь - за модульное ядро. Противоречие. Кстати, тогда речь шла о предыдущей концепции 3ОС, которая радикально отличается от новой. Теперь, когда с придирками к друг другу покончено, ответьте все-таки на следующий вопрос: Имеются ли у вас ПРИНЦИПИАЛЬНЫЕ возражения против использования в 3ОС экзоядра и вынесения всех объектов и runtime-библиотек в "рядовые" процессы? Если имеются, прошу внятно ответить, почему модульное ядро, по вашему мнению, предпочтительнее. Если у вас нет возражений - давайте конструктивно обсуждать эту концепцию. |
||
| Наверх |
|
| captain cobalt |
|
||
|
Сообщений - 49 |
Цитата из упомянутого Питера Мюллера: Pieter J. Muller писал(а): ...
Aos is an extensible (or open) system, which means that there is no strong division between user programs (applications) and the system. A safe strongly-typed language with run-time checks is used to program the system and applications, conserving the integrity of the whole. The system is an open collection of modules, with no inherent difference between system modules and application modules. In contrast, a closed system separates applications and the operating system by assigning each its own independent address space. The closed approach allows system integrity to be maintained in the face of applications that corrupt the memory assigned to them. This is essential when applications are written in unsafe languages, which are less helpful in avoiding and containing programming errors. Examples of closed systems are Unix, Windows NT and microkernel-based systems like Mach. In an extensible system, applications can call system-supplied operations directly and data can be shared directly between the system and applications, and between different applications, because a single address space is used. In a closed system, applications communicate with the operating system using supervisor calls or some other cross-address-space calling mechanism. They communicate with each other indirectly via the operating system, using interprocess communication facilities that usually require serialization of parameters, as different address spaces are used. Past experience with extensible operating systems developed at the ETH Zurich Computer Systems Institute has demonstrated that this approach can be used to build highly transparent, lean and reliable single-user workstation operating systems (e.g., Medos-2, Vamos, Oberon, ETHOS). |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
captain cobalt писал(а): ... Это всё туфта времён ДОСа. Сейчас расширяемость достигается посредством системных user-mode библиотек, типа kernel32.dll. При этом ядро остаётся изолированным, а user получает системные функции в своём адресном пространстве.
Цитата из упомянутого Питера Мюллера: |
||
| Наверх |
|
| czarker |
|
||
|
Местоположение: Москва, т.д. Сообщений - 48 |
AlexanderK AlexanderK писал(а): ... Нет друг мой, это ты не догоняешь. Я над тобой просто издеваюсь... Причём здесь мануалы? Это спецификация, реализуемая всеми мейнстримными ОС. Что-то ты не догоняешь А по теме имею сказать, что POSIX - это громоздкий стандарт, который не стоит реализовывать ни в коем случае, ибо POSIX-совместимых систем и так слишком много. Да и должность ультрапрогрессивной POSIX-совместимой ОС уже занято - GNU/Hurd(L4). И потом, совместимость с POSIX поощряет использование критического наследия. А это наследие не совместимо с попыткой абстрагирования от современной ОС-креативной догматики... Vadim Ushakov Вы меня не правильно поняли. Vadim Ushakov писал(а): ... Не вролнуйтесь, я понял. Просто я продолжаю утверждать, что POSIX не препятствует объектной ориентации, а даже наоборот её реализует. Просто терминология другая используется. И те же std*** - простейшие, и вместе с тем нагляднейшие примеры.Я хотел сказать, что POSIX категорически не подходит для чего бы то ни было объектного. По поводу объектов, марширующих по stdout - это была шутка (возможно неудачная), если вы не поняли. Vadim Ushakov писал(а): ... Я тоже так считаю. Так о чём мы спорим? czarker писал(а): ... Если под ядром здесь имелся код, работающий в 0-м кольце, то я КАТЕГОРИЧЕСКИ ПРОТИВ размещения в этом "ядре" каких-либо объектов.А иначе-то как? Не утянягивать же в ядро все объекты...  Vadim Ushakov писал(а): ... Я неточно выразился: Вы подходите к концепции 3ОС так, как будто она совпадает с мыслями, изложенными в документации 3ОС. А это отнюдь не так. czarker писал(а): ... Я не ссылался на какую-либо документацию и не цитировал ее - даже в мыслях такого не было.не надо ссылаться на документацию 3ОС - она официально признана устаревшей Vadim Ushakov писал(а): ... Именно! И рад, что Вы заметили. Тем не менее, тогда вы были против модульного ядра Linux, а теперь - за модульное ядро. И дело тут в том, что разительно изменилась концепция: если раньше был упор на производительность и платформозависимость и архитектурную стройность, то теперь ориентация на единственную среду исполнения (.NEТ) и классическую кроссплатформенность. Это делать с помощью микроядра, IMHO, неправильно. Vadim Ushakov писал(а): ... Имеются. Я уже пару-тройку раз рассказывал: Имеются ли у вас ПРИНЦИПИАЛЬНЫЕ возражения против использования в 3ОС экзоядра и вынесения всех объектов и runtime-библиотек в "рядовые" процессы? 1) Система ориентирована на исполнение только кода .NET, что автоматически повышает значимость этого элемента. И больший прирост производительности здесь будет давать больший приоритет .NET runtime. 2) Использование любого варианта микроядра (в.т.ч. экзоядра) имеет смысл только в узкоспецифической ситуации: когда в системе необходимо отделить IPC от остальных процессов и когда необходимо динамически распределять приоритеты. 3ОС в её ориентации на настольное применение совершенно не нужны обе функции. Наоборот, концепция 3ОС подчёркивает идеологию "единственного верного пути", что проще релизуемо с помощью жёстко связанного модульного ядра в монолитном использовании. Vadim Ushakov писал(а): ... Я не понял: Вы как соотносите понятия экзоядра и микроядра? Если имеются, прошу внятно ответить, почему модульное ядро, по вашему мнению, предпочтительнее. Если у вас нет возражений - давайте конструктивно обсуждать эту концепцию. Так или иначе, я с удовольствием готов поменяться с Вами ролями и задавать вопросы к Вашей концепции. Только тогда мне нужна отправная точка. Для начала подойдёт чёткое объяснение причин, по которым (1) модульное ядро не подходит и (2) экзоядро чем-то лучше других. И всё это в отношении именно 3ОС в её настоящей концепции. Но это всё, конечно, моё сугубо личное мнение. |
||
| Наверх |
|
| Vadim Ushakov |
|
||
|
Местоположение: Россия, Красноярск Сообщений - 35 |
Такое впечатление, что на всем форуме остались только я и Czarker. Сетяне, где вы?... Ау... Между тем, Czarker порадовал очередным противоречием. Даже двумя. czarker писал(а): ... Vadim Ushakov писал(а): ... Я тоже так считаю.Я категорически против размещения в этом "ядре" каких-либо объектов czarker писал(а): ... Vadim Ushakov писал(а): ... Именно!Тем не менее, тогда вы были против модульного ядра Linux, а теперь - за модульное ядро. Я не понимаю, не догоняю, до меня не доходит - зачем делать модульное ядро, если не размещать в нем никаких объектов. Ведь модули ядра - это драйвера, которые являются настоящими объектами. Как это так: драйвера будут в 3-м кольце, а в нулевом - какие-то невразумительные "модули". Это первое противоречие, теперь второе: czarker писал(а): ... Я твёрдо уверен, что концепция модульно-монолитного ядра - это крупный провал, идея, отягощённая внутренним противоречием. czarker писал(а): ... концепция 3ОС подчёркивает идеологию "единственного верного пути", что проще релизуемо с помощью жёстко связанного модульного ядра в монолитном использовании. Второе противоречие: модульно-монолитное ядро - это плохо, но для 3ОС в самый раз подойдет. У меня сложилось впечатление, что вы, Czarker, Энглера так и не прочитали. Что же, грешен - я по .NET тоже почти ничего не читал. Давайте восполним пробелы в знаниях, а то так и будем спорить не о чем. czarker писал(а): ... Никак не соотношу. Это совершенно разные концепции. Вся роль экзоядра сводится к выделению процессам АППАРАТНЫХ ресурсов. Я не понял: Вы как соотносите понятия экзоядра и микроядра? Процесс говорит ядру: "Дай мне доступ к портам 0x60-0x64." Ядро отвечает "Не могу - порты заняты." Процесс говорит пользователю: "Не могу инициализировать драйвер клавиатуры, вероятно драйвер уже запущен." Процесс: "Пожалуйста выдели 200 страниц физической памяти." Ядро выделяет, затем думает: "Выделил 200 страниц, у меня осталось свободно всего 30". И говорит первому попавшемуся процессу: "Освободите пожалуйста 50 страниц." Процесс производит сборку мусора и/или откачку страниц на внешне устройство и освобождает ресурс. Все. Никакой другой функции экзоядро не выполняет. czarker писал(а): ... Использование любого варианта микроядра (в.т.ч. экзоядра) имеет смысл только в узкоспецифической ситуации: когда в системе необходимо отделить IPC от остальных процессов и когда необходимо динамически распределять приоритеты. В exokernel нет IPC в привычном понимании. Там есть один единственный механизм - Protected Control Transfers, который быстр настолько, насколько быстро процессор переключает контексты. Поверх него можно реализовать все, что угодно - обмен сообщениями, каналы, удаленный вызов процедур и методов и т.д. В exokernel нет никаких динамических приоритетов - есть один или более процессор, на который претендует куча процессов. Как они будут его "делить" - это дело runtime-библиотеки. czarker писал(а): ... Для начала подойдёт чёткое объяснение причин, по которым (1) модульное ядро не подходит и (2) экзоядро чем-то лучше других. Я уже писал, почему экзоядро "чем-то лучше": Vadim Ushakov писал(а): ... Нет никакой необходимости в модульном ядре - вот, что я пытаюсь доказать. Все, что раньше по историческим причинам работало в 0-м кольце, может быть вынесено в обычные процессы/потоки/объекты (в зависимости от идеологии системы). При этом гарантируется: а) увеличение устойчивости б) улучшение инкапсуляции в) упрощение разработки программ Также возможно повышение производительности (если все будет спроектировано не просто правильно, а идеально). Когда я говорил "все, что раньше по историческим причинам работало в 0-м кольце", то имел ввиду и .NET, и все ее библиотеки, драйвера, диспетчеры, и прочие невразумительные "модули." Почему "модульное ядро не подходит" вам может рассказать Татенбаум и другие идеологи микроядер. Модульное ядро имеет смысл, когда мы пишем что-то вроде MS-DOS или Menuet. 3ОС заявлена, как система которой будут пользоваться - пусть не так широко как Windows, но хотя бы как BeOS. И непременно найдутся люди, которые захотят добавить в нее новую функциональность. Представьте их ужас, когда они узнают, что для этого нужно писать не "прикладной" класс/объект, а модуль ядра. Представьте негодование пользователя, когда из-за программной ошибки модуля упадет вся система и похоронит его несохраненные данные. Если мы используем exokernel, то есть всего несколько объектов, сбой которых может привести к падению системы. Логично изолировать их в отдельные процессы - и пусть все прочие объекты вызывают GPF хоть каждые пять минут - пользователь все равно имеет полный контроль над системой. Если в системе есть принципиальная возможность добавить сторонний код в 0-е кольцо, то кто-нибудь рано или поздно воспользуется этой возможностью (скорее всего это произойдет "рано"). Если система свалится после такого вмешательства, все шишки посыпятся на разработчиков системы, а не на автора модуля-"добавки." Эту проблему я уже озвучивал ранее в таком виде: "Этот драйвер не тестировался на совместимость с нашей системой, вы уверены, что хотите продолжить установку?" Пойду искать какую-нибудь серьезную книгу по .NET. Может быть в этой технологии, как в китайском Дао, есть нечто необъяснимое словами. Вы, Czarker, так и не смогли объяснить ПОЧЕМУ .NET требует модульного ядра. Единственный ваш аргумент: "IMHO, .NET требуется модульное ядро." Если найду в ней это самое Дао, которое обесценивает все мои доводы, - публично раскаюсь в заблуждениях. P.S. Если я исчезну с форума недели на две-три, то это вызвано техническими причинами, вы меня не теряйте I'll be back... [ Редактирование Saturday 12.02.2005 14:58 ] |
||
| Наверх |
|
Модераторы: Roman I Khimov, netwizard. |
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |