Ответ на »сообщение 2658« (Zuzza)
___________________________

У системы должны быть: 1 - четко определенный список задач прикладного уровня, 2 - Типы аппаратных архитектур или ТЗ на разработку своей архитектуры, 3 - целевая аудитория пользователей/заказчиков. Вообщем что я ученых-то учу. Сачала бизнес треботвания, птотом остальные.

Я не совсем ученый. Точнее, совсем не ученый. Что впрочем, можно увидеть из следующей заметки: http://rbogatyrev.livejournal.com/2007/05/31/

Бизнес-требования -- это хорошо. Это важно. Только давайте задумаемся вот над каким простым вопросом: чтобы формулировать бизнес-требования, надо ли знать этот самый "бизнес"? О каком бизнесе мы рассуждаем? Кто сказал, что мы сейчас делаем ПРОДУКТ для рынка, для бизнеса?

Есть очень простые предпосылки нашего проекта (далее под словом "мы" буду иметь в виду инициативную группу, включающую в себя техсовет проекта и ряд участников):

1. В настоящее время мы видим проблемы доминирования Windows-семейства и противостояния Linux. Проблемы технологические, проблемы социальные, проблемы экономические.
2. Мы имеем четкое представление о том, что новые процессорные архитектуры не могут эффективно использоваться существующими ОС (не только Windows и Linux). Это глубинные проблемы. Научно-технологического характера.
3. Мы знаем, что в области работ европейской школы проф. Вирта (ETH Zurich) за три с половиной десятилетия накоплен богатый неиспользованный потенциал. Причина: технологический, научный и маркетинговый изоляционизм.
4. Члены нашей группы обладают знаниями, опытом и результатами собственного детального мониторинга деятельности Вирта и его коллег за период в четверть века, а также пониманием проблем разработок Вирта и путей их решения. Что мы рассматриваем как свое конкурентное преимущество перед другими группами.
5. У нас имеются заделы (научные и технологические) в области системного программирования, не относящиеся к работам виртовской школы, которые пока не были использованы на практике. Носители этих знаний и технологий входят в состав инициативной группы.
6. Мы имеем твердое желание создать новую ОС (семейство ОС), которая была бы открытой (со всеми исходными текстами), бесплатной, без ограничений на коммерческое использование и продумали пути достижения этой цели. Наша цель -- создать высококачественную надежную ОС, исходя из собственных представлений о качестве, планка которого поднимается много выше известных нам коммерческих систем.
7. Мы понимаем, что приоритет технологического совершенства, создаваемого группой специалистов-единомышленников в условиях свободного творчества, требует принципиально иного подхода к работе -- приоритета исследований, что отражено в нашей концепции Open Research Programming.
8. Мы ставим перед собой цель проведения НИОКР до начала производства новой ОС (где и будут формулироваться конкретные бизнес-требования к превращению полуфабриката в продукт).
9. До начала НИОКР мы проводим предпроектные изыскания с целью выявления возможных ниш (проблемных, технологических, рыночных) и процессорных архитектур, которые потребуется учетывать при создании полуфабриката ОС (макета и сопутствующей документацией).
10. В случае невозможности перехода к стадии производства продукта (из-за недостаточного ресурсного обеспечения по завершении НИОКР) мы рассматриваем вариант изготовления из полуфабриката ОС продукта, предназначенного для сферы автоматизации научных исследований в рамках финансирования по линии европейских проектов (запасной вариант).

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

Некоторые вопросы изложены в заметке "Пути восхождения к новой ОС": http://rbogatyrev.livejournal.com/2007/08/31/

Все, что Вы перечислили, имеет смысл в большей степени при переходе от НИОКР к производству. Скорее всего, с учетом наших планов, речь может идти примерно о 2009-2010 гг. Тем не менее НИОКР будут проводиться в рамках ТЗ, которые готовятся после завершения процесса начальных консультаций и выработки основы для проведения проекта -- манифеста проекта. Его подготовка сейчас ведется и намечена на октябрь.

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

Ответ на »сообщение 2616« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 2585« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2579« (Сергей Прохоренко)
___________________________

Это большое заблуждение. Графическое представление ориентировано на конструирование принципиально нового. Текстовое - на уточнение с помощью образцов из старого, если графическое не содержит таких образцов.

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

Недостаток один: требуется проделать РАБОТУ, чтобы устранить в графическом интерфейсе то, что мешает, и добавить то, что нужно, а также придумать, что же нужно, чтобы минимальными усилиями пользователь получил максимальный результат.
Я, конечно, не знаю, насколько интенсивно вы используете графические модели, но, Вы уж извените, мне кажется, что не очень часто.
Вот, к примеру нашли единственный недостаток графических моделей. Сделайте, пожалуйста, графическую РАБОТУ, иллюстрирующую пути обхода ошибок и добавления важного функционала к графическим инерфейсам.

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

P.S. Моё мнение дилетанта: мат. модели первичны (предпосылка чего-то нового), а графика вторична (следствие чего-то, возможно, нового).

Ответ на »сообщение 2658« (Zuzza)
___________________________

Сачала бизнес треботвания, птотом остальные.
Это мы уже обсуждали пару тысяч сообщений назад :)
Разработчики "Росы" хотят использовать процесс, который гораздо ближе к (фундаментальным) научным исследованиям, а не к разработке решений для бизнеса.

Ответ на »сообщение 2619« (Сергей Перовский)
___________________________

Ответ на »сообщение 2593« (Beginner)
___________________________
Язык моделирования же - рисунок.
А по моему язык моделирования это математика :)
Вообще непонятно, откуда пошли разговоры про рисунки. Те оппоненты, которые выступают на стороне графических моделей явно что-то упускают. Автор статьи напирает на важность моделей и нигде в своей статье не приводит примеров?! Как можно доверять такому автору? С другой стороны, если бы они читали внимательно, то заметили бы, что из всех возможных классов моделей выделяется один. Я не знаю почему сделано именно так (разговор ведётся про частный случай, а упоминаются модели вообще, хотя логического обобщения сделано не было), попахивает... фанатизмом, что ли.

P.S. А пример там всё-таки есть.

Ну сделайте же наконец Столману ядро для GNU, что бы всем стало хорошо. А то он сам-то, бедяга, уже 30 лет мучается и все никак.

Ну а если без шуток, то на кого все-таки операционная система-то ориентирована? Система для программистов? Так таких уже хватает. Для ученых? У них уже есть mat[lab|cad|...]. Для пользоваталей? Тогда на каком железе она будет работать? На отечественном? Какова архитектура железа? Почему никто не задается проблемами интерфейса человка и машины? (То что тут говорились - это интерфейс от программистов для программистов). Кто-нибудь г-на Раскина читал? Сформулируйте что Вы хотите сделать. Только не говорите, что это евро-русская ОС общего назначения нацеленная на обычную PC-архитектуру. Сказать так - значит ничего не сказать. У системы должны быть: 1 - четко определенный список задач прикладного уровня, 2 - Типы аппаратных архитектур или ТЗ на разработку своей архитектуры, 3 - целевая аудитория пользователей/заказчиков. Вообщем что я ученых-то учу. Сачала бизнес треботвания, птотом остальные.
После определения всех внешних требований имеет смысл определиться с теми "новинками", которые вы хотите имеь в системе. Если более 30%, то стоит серьезно задуматься. Правило 30% принято в любой технике. Новинки, выходяие за границу 30% стоит обкатать на существующих ОС и окружениях, иначе рисукете погибнуть под градом багов и запросов на доработку, и даже открытая модель врятли поможет.

Ответ на »сообщение 2638« (Beginner)
___________________________

Верификация на соответствие разъёмам блоков? На логические тупики?

Может есть ссылка по освещению темы схем сопряжения или укажите, пожалуйста, аналог?
Не знаю, хватит ли моего опыта быть полезным, но поиграться такими сетями чешутся руки. Тем более время есть.

Это мои проработки очень старой давности (конца 1980-х -- начала 1990-х годов). Я о них вспомнил года три назад, когда обратил внимание, что в этом направлении за 20 лет подвижки были весьма скромные. В прошлом году плотно засел за идею новой ОС, но многие вопросы оставлены на детальную проработку. Надеюсь плотнее ими заняться после выстраивания процесса работы и раскатки проекта. Сейчас очень много времени уходит на "раздувание пламени", а не собственно на процесс приготовления еды.

У нас коллективное творчество. И если кто-то выдвигает ценные идеи -- мы не отбрасываем этот вариант, а будем его прорабатывать. Это еще один стимул работы в проекте. Участник работает не только на себя, но и может пробовать им же выдвинутую идею, причем в помощь ему могут отряжаться необходимые ресурсы, включая других участников, консультации, доступ к литературе и т.п.

Если Вы хотите сами попробовать, я дал для этого достаточно информации. Начинайте с книги Питерсона (это некий ликбез), потом смотрите монографию Котова. Обе книги есть на EuroProg: http://www.europrog.ru/ilog.html#030407

Посмотрите ссылки, которые я давал в отношении старых работ (LOTOS). Копните состояние дел в этой области (Petri Nets), раскрутив отправные источники информации, например, через Wikipedia. Поищите близкие или подобные вещи. Почитайте, поанализируйте. Продумывайте свои идеи и пробуйте их (мысленно или программно).

Появится мотивация участия в проекте -- можно будет к нему подключаться. Работы у нас выше крыши. Только, в основном, больше мозгами надо работать, а давить на кнопочки -- пока что надо много меньше.

Ответ на »сообщение 2655« (Руслан Богатырев)
___________________________

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

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

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

Ответ на »сообщение 2654« (panda)
___________________________

>Проблемы UNIX известны (мы отдельно опубликуем их разбор)
Если Вам будет не очень сложно, после опубликования поместите здесь ссылку. Было бы интересно почитать разбор проблем UNIX с точки зрения разработчиков "Росы".

Обязательно сообщу. Все документы по проекту (а первый год во многом будет исследовательский) мы будет открыто размещать на сайте проекта (в рамках europrog.ru). Анализы и обзоры более менее значимых систем и решений, попавших в поле нашего зрения. Это будут реальные рещультаты стадии исследований. И можно будет в форумах получить обратную связь на эти работы, что позволит нам скорректировать некие решения.

>Качественно иные средства мультипрограммирования (асинхронное, параллельное, конкурентное)
Кстати, недавно представителям Intel задали вопрос: "Предполагается ли что-нибудь сделать в новых процессорах, чтобы резко повысить эффективность системы, состоящей из множества маленьких параллельно работающих объектов? Сейчас переключение контекста потоков сильно тормозит" (за точность цитаты не ручаюсь). На что был дан ответ, что с точки зрения процессоров все работает очень даже неплохо. И проблема заключается исключительно в Windows и Linux с их неэффективными планировщиками потоков. "Пишите свою ОС", - заявил представитель Intel ;-)

И правильно он сказал. Проблема давно известна, несколько десятилетий с ней по-разному борются, но в ПК-мэйнстриме она спускалась на тормозах. А вот сейчас, когда речь пошла о многоядерных процессорах (с числом ядер более 100), начинают задумываться, как быть.

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

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

Ответ на »сообщение 2651« (Руслан Богатырев)
___________________________

Проблемы UNIX известны (мы отдельно опубликуем их разбор)
Если Вам будет не очень сложно, после опубликования поместите здесь ссылку. Было бы интересно почитать разбор проблем UNIX с точки зрения разработчиков "Росы".

Качественно иные средства мультипрограммирования (асинхронное, параллельное, конкурентное)
Кстати, недавно представителям Intel задали вопрос: "Предполагается ли что-нибудь сделать в новых процессорах, чтобы резко повысить эффективность системы, состоящей из множества маленьких параллельно работающих объектов? Сейчас переключение контекста потоков сильно тормозит" (за точность цитаты не ручаюсь). На что был дан ответ, что с точки зрения процессоров все работает очень даже неплохо. И проблема заключается исключительно в Windows и Linux с их неэффективными планировщиками потоков. "Пишите свою ОС", - заявил представитель Intel ;-)

Ответ на »сообщение 2652« (Александр)
___________________________

Хорошо Линукс не совершенная ОС, а не проще откатиться на какую либо раннюю версию ядра Линукса и с этой точки начать разрабатывать свою ОС (как это сделал Мэтью Дилан с DragonflyBSD)?

Зачем делать как другие? Очевидным путем? Мы ведь собираем команду для того чтобы создать классную ОС (это во-первых), а во-вторых, чтобы дать своей стране реальную альтернативу существующим. Ведь иметь свою (государственную ОС) страна сейчас не может. Клоны Linux? Это несерьезно. А думать надо не только о сегодняшнем дне.

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

Судя по вопросу понимаю, что Вы не следите постоянно за этим форумом. Я Вам кратко здесь отвечу, но рекомендую ознакомиться с материалами в моем блоге, включая и статью "Нужна ли Россия своя ОС" (там ссылка есть). Вот конкретная заметка с ответом на Ваш вопрос: "Государственная ОС" (http://rbogatyrev.livejournal.com/2007/05/28/). Посмотрите оглавление в моем блоге и прочитайте лругие заметки. Думаю, многие вопросы снимутся сами собой (и появятся другие).

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