Здравствуйте!
Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой
ОС. Причём не только русской, но и всего русскоговорящего населения?
Присоеденились бы вы к такому проекту?
Прошу не относить к флейму. Речь идёт о уже существующем проекте.
С уважением,
VICH
Всего в теме 5452 сообщения
Отслеживать это обсуждение
№ 2222 18-08-2007 08:50 | |
Ответ на »сообщение 2220« (Сергей Прохоренко)
___________________________
Одна ссылка не пропечаталась:
4. Виртуализация http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=10813
На сайте radisys.com есть описание системы OS-9.
Мне понравилось The Top Seven Reasons to Choose OS-9:
...
2. Reliability and security: OS-9’s elegant modular architecture and use of processor MMUs protect against memory faults and application errors that crash other RTOSes.
...
5. Standards Compliance: Enhanced portability with support for BSD-Sockets, IPv6 and POSIX Threads. Customers have rapidly ported applications from Linux to OS-9 in days instead of weeks that other RTOS require.
Особенно хочу отметить п.5. Наличие POSIX совместимости, видимо, вещь очень важная для RTOS, уж если это выносится в top seven.
Это еще один аргумент в жарком споре "а надо ли POSIX?.." в пользу "надо!".
Документ с того же сайта http://www.radisys.com/products/OS-9_Selection_Methodology_RTOS_Market.pdf
дает описание методики оценки систем реального времени.
Можно получить представление о механизме выбора ОС для аэрокосмической отрасли, будущих конкурентах и проблемах ОС реального времени.
№ 2221 18-08-2007 08:03 | |
Спасибо за ссылки - очень интересный материал!
№ 2220 18-08-2007 07:39 | |
№ 2219 18-08-2007 07:34 | |
Ответ на »сообщение 2216« (Руслан Богатырев)
___________________________
Ответ на »сообщение 2208« (Eeyore)
___________________________
Например, наличие/отсутствие MMU может повлиять на архитектуру
Безусловно, ПОВЛИЯТЬ может.
Если очень упрощенно представлять себе, что архитектура ОС -- это организованная совокупность (абстрактных) значимых элементов (подсистем), а также правила их сосуществования (взаимодействия), то степень влияния тех или иных элементов (подсистем) обусловлена и подходами к абстрагированию. Это абстрагирование рано или поздно имеет дело с конкретикой -- аппаратной архитектурой.
Таймер и аппаратное управление памятью -- важные вещи, от которых просто так отмахнуться, разумеется, нельзя. Именно поэтому внутри нашей группы ведутся столь жаркие дебаты по поводу MMU и потенциальных (целевых) процессорных архитектур.
Например, приводилась довольно радикальная точка зрения Вирта и Гуткнехта: "Its side effects on execution speed are essentially unpredictable. This makes systems with MMU virtually unusable for applications with tight real-time constraints". (Wirth, Gutknecht. Project Oberon. 2005)
На мой взгляд, говоря об абстрагировании ОС от оборудования нельзя бросаться и в другую крайность -- когда для каждой процессорной архитектуры предусматривается своя новая архитектура ОС. Архитектура ОС должна по возможности демпфировать различия целевой аппаратуры, переводя их в плоскость своей реализации. А вот как осуществляется реализация архитектуры ОС, исключительно ли на языке программирования -- это отдельный вопрос, требующий внимательного изучения.
Находки в интернете:
1. Для приложений жесткого реального времени и для приложений общего назначения (например, GUI) могут использоваться разные разделы памяти, различным образом организованные: http://www.radisys.com/products/datasheets/images/os9/dev_kit/os9_devkit_fig02.jpg
2. Взгляд Microsoft на будущее операционных систем: http://www.ctwatch.org/quarterly/articles/2007/02/the-many-core-inflection-point-for-mass-market-computer-systems/
3. eBook - Informations about Operating Systems http://www.operating-system.org/betriebssystem/download/OSDP_eBook_operatingsystems_230707.pdf
4. Виртуализация http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=10813
5. Виртуализация http://turbovps.com/page.php?8
6. The Philosophy of Neutrino http://rdimitr.chat.ru/qnxarch/intro.html
7. Важнейшим из ресурсов, распределением которого должна заниматься ОС, является внимание пользователя к тем или иным темам, задачам, приложениям, документам, жанрам, страницам, письмам, контактам, видам деятельности, товарам, веб-сервисам, точкам на карте и т.п. http://www.usingattention.com/wp-images/TheAttentionLifeCycle_15083/the-attention-life-cycle.jpg
Т.е., нужен ДРАЙВЕР ВНИМАНИЯ ПОЛЬЗОВАТЕЛЯ.
Это вовсе не шутка. На смену поиску по имени в дереве папок и файлов и поиску по четким критериям (расширение файла, ключевые слова в имени или теле файла, даты создания и последнего изменения и т.п.) должен прийти ассоциативный поиск (например, такой-то документ был создан после просмотра такой-то веб-страницы, и в него была скопирована часть такого-то письма) и GUI с искусственным интеллектом (разумеется, без таких уродств, как «Скрепыш»).
Наверное, истекает время файловых систем, в которых файлы находятся в иерархических папках и имеют одно расширение имени. В будущем каждый файл будет иметь неопределенное количество значений атрибутов различных типов, а ассоциативные связи между файлами будут описываться соответствующими таблицами. Виртуальные папки – только первый шаг в этом направлении.
Правда, придется крепко подумать о приватности пользователя. Упрятывание документов (и вообще, всех вещей, которые пользовались вниманием пользователя) от постороннего взгляда должно быть реализовано в новой ОС «по умолчанию».
8. Версионность (с возможностью отката к ранее сохраненным версиям), сохранение резервных копий и синхронизация документов в интернете и на флэшках тоже должны поддерживаться на уровне ОС, чтобы не приходилось плодить файлы со слегка различными именами в разных папках.
№ 2218 18-08-2007 05:10 | |
Ответ на »сообщение 2217« (Руслан Богатырев)
___________________________
А почему? Потому что Линус Торвальдс такими "пустяками" при своей работы над Linux и не озадачивался. Его подход был прост до безобразия -- взять готовую модель (Minix), взять готовый софт (GNU), а затем на новой аппаратуре (x386) начать реализовывать модель с нуля и отслеживать готовность реализации по принципу "задымит -- не задымит". Впрочем, это достаточно подробно описано в его книге Just for Fun: The Story of an Accidental Revolutionary ("Just for Fun. Рассказ нечаянного революционера"). Ну а когда гром грянул, пришлось сильно чесать в репе.
Разве мог молодой студент предположить, что его операционную систему, поделку just for fun, придется портировать на другой процессор?
Даже сам Бил Гейт сказал про себя и свою компанию - "Мы не провидцы, но приспособленцы".
По-видимому, единственно правильный способ разработки программ и систем - эволюционный. Что не снимает с вас необходимости продумать все заранее, и не совершать ошибки Торвалдса и Гейтса.
№ 2217 18-08-2007 01:34 | |
Ответ на »сообщение 2214« (Eeyore)
___________________________
Кстати, даже в рамках одной процессорной линейки x86 сколько пришлось изменить в "АРХИТЕКТУРЕ Linux" при адаптации под SMP-системы?
А почему? Потому что Линус Торвальдс такими "пустяками" при своей работы над Linux и не озадачивался. Его подход был прост до безобразия -- взять готовую модель (Minix), взять готовый софт (GNU), а затем на новой аппаратуре (x386) начать реализовывать модель с нуля и отслеживать готовность реализации по принципу "задымит -- не задымит". Впрочем, это достаточно подробно описано в его книге Just for Fun: The Story of an Accidental Revolutionary ("Just for Fun. Рассказ нечаянного революционера"). Ну а когда гром грянул, пришлось сильно чесать в репе.
№ 2216 18-08-2007 01:26 | |
Ответ на »сообщение 2208« (Eeyore)
___________________________
Например, наличие/отсутствие MMU может повлиять на архитектуру
Безусловно, ПОВЛИЯТЬ может.
Если очень упрощенно представлять себе, что архитектура ОС -- это организованная совокупность (абстрактных) значимых элементов (подсистем), а также правила их сосуществования (взаимодействия), то степень влияния тех или иных элементов (подсистем) обусловлена и подходами к абстрагированию. Это абстрагирование рано или поздно имеет дело с конкретикой -- аппаратной архитектурой.
Таймер и аппаратное управление памятью -- важные вещи, от которых просто так отмахнуться, разумеется, нельзя. Именно поэтому внутри нашей группы ведутся столь жаркие дебаты по поводу MMU и потенциальных (целевых) процессорных архитектур.
Например, приводилась довольно радикальная точка зрения Вирта и Гуткнехта: "Its side effects on execution speed are essentially unpredictable. This makes systems with MMU virtually unusable for applications with tight real-time constraints". (Wirth, Gutknecht. Project Oberon. 2005)
На мой взгляд, говоря об абстрагировании ОС от оборудования нельзя бросаться и в другую крайность -- когда для каждой процессорной архитектуры предусматривается своя новая архитектура ОС. Архитектура ОС должна по возможности демпфировать различия целевой аппаратуры, переводя их в плоскость своей реализации. А вот как осуществляется реализация архитектуры ОС, исключительно ли на языке программирования -- это отдельный вопрос, требующий внимательного изучения.
№ 2215 17-08-2007 16:32 | |
Ответ на »сообщение 2213« (Илья Ермаков)
___________________________
Ответ на »сообщение 2212« (Сергей Прохоренко)
___________________________
Ответ на »сообщение 2210« (whitetown)
___________________________
Тем более, что возможно применение тройного модульного резервирования, дающего практически 100-процентную отказоустойчивость.
Однако до тех пор, пока там Windows, резервирование от ошибок софта поможет мало :-)
Садиться за руль машины, у которой нет прямой связи между рулём и колесами и педалью тормоза и колодками... зная, что там винда... ох как опрометчиво....
Конечно, ведь одна и та же программная ошибка возникнет в каждом из трех микроконтроллеров.
Поэтому я абсолютно уверен, что между педалью тормоза и тормозными дисками Windows нет. Далеко не на всех контроллерах вообще есть операционная система. Если функции данного микроконтроллера очень узкие, то программа на ассемблере или Си (без плюсов) (редко - на Паскале) жестко зашивается в ПЗУ с помощью программатора - устройства, подсоединенного как к микроконтроллеру, так и к настольному компьютеру. И файловая система в этом случае тоже не нужна - файлов просто нет.
Windows можно использовать только в системах кондиционирования воздуха, навигации, мультимедийных развлечений, противоугонных системах и т.п. А для "управления автомобилем по проводам" нужна надежная ОС жесткого реального времени, или не должно быть вообще никакой ОС.
№ 2214 17-08-2007 15:56 | |
Ответ на »сообщение 2209« (panda)
___________________________
Лучше расскажите, чем отличается АРХИТЕКТУРА Linux на мейнфрейме и АРХИТЕКТУРА Linux в Nokia 770.
А что, в этой самой Nokia нет MMU? :-)
С точки зрения Unix-подобной системы важна не столько система команд или количество регистров, сколько другие качества архитектуры, например, наличие аппаратной защиты памяти (хотя бы простейшей, вроде разделения памяти на доступную пользовательскому коду/супервизору) или таймерного прерывания для организации вытесняющей многозадачности. По этим (и им подобным) параметрам мейнфрейм на Power и КПК на ARM принципиально не отличаются, поэтому и немудрено, что Linux переносится на них без радикальных изменений. А для сравнения попробуйте прикинуть, как выглядит реализация того же fork() на системах без аппаратного управления памятью (типа 8086). В принципе возможно, но это такое душераздирающее зрелище...
Кстати, даже в рамках одной процессорной линейки x86 сколько пришлось изменить в "АРХИТЕКТУРЕ Linux" при адаптации под SMP-системы?
№ 2213 17-08-2007 14:52 | |
Ответ на »сообщение 2212« (Сергей Прохоренко)
___________________________
Ответ на »сообщение 2210« (whitetown)
___________________________
Тем более, что возможно применение тройного модульного резервирования, дающего практически 100-процентную отказоустойчивость.
Однако до тех пор, пока там Windows, резервирование от ошибок софта поможет мало :-)
Садиться за руль машины, у которой нет прямой связи между рулём и колесами и педалью тормоза и колодками... зная, что там винда... ох как опрометчиво....
Отслеживать это обсуждение
Дополнительная навигация: |
|