Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 3, Пользователей: 1 ...
Roman I Khimov смотрит rss.php
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
Roman I Khimov смотрит rss.phpрекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Общие :: Разное |
|
<< Предыдущая тема | Следующая тема >> |
| Язык как основа операционной системы | ||
| Переход на страницу 1 2 3 ... 6 [7] 8 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Hmmm |
| ||
  ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | ossadchy написал(а) ... 1. Система разрабатывается на базе единной объектной системы - это уменьшает дублирование как исходного кода так и уменьшает объем загруженного в память бинарного кода. Вместе с тем это не означает что все пишется на ОДНОМ языке. 2. Может отсутстовать как таковое деление на адресные пространства. В работах по L4 (посвященным small address spaces) приведены исследования которые показывают что источник трат времени в микроядерных системах -- как раз переключение адрессных пространств. 3. При размещении всех компонент в едином адресном пространстве ищезает проблема обеспечения коммуникаций между задачами пользователя -- IPC заменяется простым вызовом метода или посылкой сообщения. 4. Не составляет проблем сделать прозрачным взаимодействие объектов находящихся на разных машинах. По-настоящему ОО языки дают такие возможности -- Java, C#, Objective-C, Smalltalk -- кое-что у них можно позаимствовать. 5. Единый набор базовых классов, инструментов и подходов к разработке всех компонент системы -- например, драйвера устройств могут задействовать всю мощь системной библиотеки классов для решения задач взаимодействия с периферией. Все это экономит усилия программистов и ускоряет процесс разработки. 6. Униформный интерфейс всех компонент системы, что фактически "выводит за кулисы" множество проблем взаимодействия между оными(компонентами) - не надо изобретать методов посылки сообщений, ищезает понятие системного вызова как такового(достаточно накладный процесс, даже при задействии "быстрых" системных вызовов), для того чтоб взаимодействовать с любым процессом достаточно изучить API(который легко можно генерировать используя инструменты типа doxy, javadoc и т.д.). Другими словами вы предлагаете использовать в качестве основы единое дерево классов, где каждый новый класс является порождением от уже существующих. Один маленький нюанс, такое дерево рано или поздно приведет к необходимости множественного наследования которое, как мне известно, в полной мере реализовано пока только в С++. Нет никаких проблем к использованию единого адресного пространства, за исключением того что плохо написаный код сможет на раз-два порушить всю систему, а уж про вредоносный я вообще молчу. Это не аргумент против, это лишь указание на необходимость наличия механизма верификации кода при инсталляции. Механизмов подобной верификации можно предложить множество. Механизмы IPC в основном подразумевают наличие синхронизации, не более того. В юниксах есть такая штука как разделяемая память основные проблемы начинаются когда нужно синхронизировать потоки данных. Для вызова методов одной машины с другой сейчас можно воспользоваться механизмом "дверей". Основной упор следует делать не на создании языков в которых сложно допустить ошибку или компиляторов "исправляющих" допущенные ошибки, а на создании эффективной системы отладки программ. Именно такой подход экономит уйму времени, поскольку позволяет упростить отлов пресловутых 10% труднообнаруживаемых багов. В этом плане замечательная штука - сановский dtrace. Фактически отладчик встроенный в ядро ОС. При помощи него можно не только мониторить состояние своего процесса но даже наблюдать за работой ядра. Более того, если ваш код заглючил у заказчика и это поведение является трудновоспроизводимым вам достаточно переслать заказчику сценарий для dtrace который выдаст требуемую информацию о работе вашего кода, фактически предоставляя вам возможность удаленной отладки. При этом отладкой занимаетесь разумеется вы. | ||
| Наверх | | ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | ossadchy написал(а) ... Сейчас все следует делать с прицелом на 64 бита -- за этим будущее. Вместе с тем не исключается возможность работы в 32х битах -- 4Г для большинства настольных систем сегодня -- даже не ограничение. Системы с большей памятью как правило уже могут работать в 64 битах -- а это теоретически 2^64 байт памяти. Честно говоря не вижу в современных x86-64 каких либо выгод по сравнению с IA32. Производительности это практически не дает. Так, костыли какие-то. Если это наше будующее... Я не хочу там жить!!!  ossadchy написал(а) ... Нравится, спокойней -- славянский подход. Ну а если осмыслить суть подхода? Ведь просто есть замена привычным нам механизмам -- в чем страх? Dron написал(а) ... Тока фраза 'например, драйвера устройств могут задействовать всю мощь системной библиотеки' немного пугает Опять же пугает Такое впечатление, что ты пытаешься уговорить меня попробовать новую операционную систему, а я отнекиваюсь... нету таких систем, кроме Bluebottle, который меня почему-то не возбуждает. ossadchy написал(а) ... Ну конечно можно и просматривать, просто удобно когда есть спецификация API и она изменяется синхронно с изменением кода. Если меняеся.... программисты никогда не документируют свой код! Да, я знаю что должны... но doxygen и так прекрасно расписывает все переменные Максимум на что я готор в коде - это строчечка комментария А когда я смотрю на прототипы WinAPI - там кода не видно... там одна документация, средств для просмотра которой нету.Уж гораздо лучше толковая дока, которая не разбавлена кодом и которая естественно должна вовремя обновляться. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| cmp |
| ||
| ID пользователя #279 Зарегистрирован: Понедельник 18.04.2005 15:35Сообщений: 131 | Ну допутим, что программист это некоторый генератор буковок и циферок, которые очень напоминают некий код, который даже компилится в ОС. Хотелось бы узнать каким образом пользователь работающий в этой ос может посмотреть сколько трафика он использовал, точнее что происходит между нажатием кнопки и появлением цифры на экране, желательно с коментариями по поводу того что контролирует правильность выполнения того или иного куска. | ||
| Наверх | | ||
| Chizh |
| ||
 ID пользователя #90 Зарегистрирован: Понедельник 13.09.2004 18:42Сообщений: 170 | Мне кажется, правильность контролирует не что, а кто. А траффик считается обычным счётчиком загрузки CPU, который есть в любой системе (в Windows в меню Administration / Performance). | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | 2Hmmm: 1. Ну не забываем что языки-то мы задействуем типо безопасный -- никто ничего не может порушить по определению -- для обхода использования некорректных бинарников, которые получает система из вне всегда можно задействовать верификацию кода или распространение в некой промежуточной форме, которая может являться просто компактным представлением исходной программы 2. Множественное наследование... ну обходятся без него -- это скорее костыль чем то что необходимо для разработки ОО-программ 2cmp: контролирует все компилятор и подсистема установки новых классов 2dron: не уговариваю попробовать новую ОС. просто предлагаю быть объективными и обсуждать действительно проблемные стороны подхода -- думаю напрячься в этом направлении будет полезно всем интересующимся построением ОС -- ведь это не дело замкнуться в своих мыслях и просто отрицать все предлагаемое другими -- это путь в никуда. тем более если основываться не на логических умозаключениях а на чувствах и предчувствиях. | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | 2dron: о системах типа doxygen как раз и говорю и сгенерированный из исходника документ не должен содержать кода 2Hmmm: механизмы IPC предполагают и передачу данных -- shared memory, каналы, сокеты, мэйлбоксы -- все это для передачи данных и все это делает систему менее стройной и простой ибо связать 2 программы на одном компе задача часто не тривиальная и требует написания немалого количества кода Системы отладки должны быть и более того должны быть удобней, но давайте посмотрим правде в глаза -- все технологии которые сейчас позиционируются как технологии будущего в сути своей ОО языки, которые проводят контроль корректности типов и не позволяют пользовать указатели -- так почему не строить ОС на них? [ Редактирование Вторник 16.10.2007 21:18 ] | ||
| Наверх |
| ||
| Hmmm |
| ||
| ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | 2ossadchy Вы, простите, какой опыт программирования имеете и на чем? Просто у меня сложилось впечатление что опыта практического программирования у вас почти нет. Дело в том, что даже в рамках одной многопоточной программы проблема синхронизации уже стоит. А shared memory механизм в общем очень не сложный. Да и связать две программы на одном компе этож как нефиг делать, одна программа создает файл а другая его открывает, так собственно именованный канал и работает. И этот случай как раз много проще разделяемой памяти, поскольку синхронизации не требует. | ||
| Наверх | | ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | [quote] Hmmm написал(а) ... 2ossadchy Вы, простите, какой опыт программирования имеете и на чем? Просто у меня сложилось впечатление что опыта практического программирования у вас почти нет. Дело в том, что даже в рамках одной многопоточной программы проблема синхронизации уже стоит. А shared memory механизм в общем очень не сложный. Да и связать две программы на одном компе этож как нефиг делать, одна программа создает файл а другая его открывает, так собственно именованный канал и работает. И этот случай как раз много проще разделяемой памяти, поскольку синхронизации не требует. Никто не говорит что проблем синхронизации нет. Обсуждаемый подход решает проблему передачи данных избегая накладных расходов на копирование, перемещение и снимает вопрос проверки корректности передаваемых сообщений. Нефиг делать -- но можно и проще без написания дополнительного кода. Я не говорю что механизмы сложные, но 1. они накладные по ресурсам 2. они делают процесс связывания программ достаточно сложным в случае если нужно передавать параметры разных типов и строить сложные схемы взаимодействия процессов и задача это далеко не тривиальная -- просто если для вас "я однажды это сделал" аргумент доказывающий простоту чего либо то понятно откуда такие рассуждения 3. они очередное отступление от принципа униформности, давайте посмотрим на среднестатистическую ОС, там есть: -- вызовы функций, процедур, методов(не суть важно как это называть) внутри программы -- системные вызовы -- межпроцессное взаимодействие все это усложняет систему, а я за простоту А опыт некоторый в разработке ПО прикладного и системного имеется. C, C++, Objective-C, Java, C#, Delphi, PHP, Assembler. Но не мою персону здесь обсуждаем - она мне даже мало-мальски не интересна .[ Редактирование Вторник 16.10.2007 23:38 ] | ||
| Наверх |
| ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | ossadchy, А сколько лет занимаешься программированием? языки - это ИМХО не главное... Кстати вот такой аспект... не знаю как 64 бита которые помоему нафиг некому не нужны... но вам не кажется что системам тесно в пределах одного компьютера??? Здесь уже затрагивались аспекты многопоточности... но есть еще и многопроцессорность не только в локальном, но и в глобальном (взаимодействие машин) плане... Я тоже за простоту... Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | ну меня спросили какие языки я использую -- я отписал. комерчески применяю свои знания и умения в области программирования на протяжении 5 лет. в целом занимаюсь программингом уже 10 лет. из последнего -- http://weblancer.net/users/ossadchy ну и http://ossadchy.net. ОС и системный программинг -- мое давнее хобби. Будучи студентом первого курса разработал свою первую многозадачную ОС с монолитным ядром. Есть разработанные микроядра, библиотеки для системного программинга, писал свой язык(frontend для gcc) -- но все это не считаю в данный момент сколь нибудь достойным внимания постороннего человека, хотя по возможности буду знакомить сообщество со своими наработками ибо понимаю что многие из них могут быть интересны начинающим осеписателям. Иногда балуюсь написанием ПО для микроконтроллеров AVR. Кому нужны какие исходники, примеры, консультации в области построения ОС(монолитных, микроядерных) -- пишите в приват, чем смогу -- помогу. В ближайшее время хочу выставить на обозрение свою концепцию построения микроядра - в некоторой мере являющуюся обобщением подхода l4 с его отображением ресурсов. В последнее время формируется образ ОС моей мечты Надеюсь смогу выделить время-деньги на реализацию своих замыслов.Но, если чесно, говоря -- есть дискусия и очень плохо что многие пытаются уличить собеседника в некомпетентности -- думаю мало кто из людей такого типа тут регистрируется и общается. Не вопрос в том что я умею или знаю -- я просто даю тему для обсуждения. Ведь и я могу поинтересоваться кто и чем "дышит" -- но мне, чесно говоря это совсем не интересно ибо ресурс посвящен не персонам(тем более нашим с вами ) а технологиям.64 бита -- через некоторое время в 32х битах даже счетчику времени UNIXовому станет тесно. Пока широко распространенные платформы 64 бит -- костыли, но время лечит. По поводу масштабируемости на распределенные системы -- уже писал. Легко надстраиваются механизмы ПРОЗРАЧНОЙ передачи сообщений по сети -- т.е. никто не почувствует разницы в программировании локальных и распределенных приложений. [ Редактирование Среда 17.10.2007 00:18 ] | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 6 [7] 8 ... 15 16 17 | |
Powered by e107 Forum System