> man operating_systems
Переход на страницу  1 2 3 [4] 5 ... 10 11 12
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
brasset
Воскресенье 10.07.2005 01:59
ID пользователя #198
Зарегистрирован: Среда 02.02.2005 13:17
Местонахождение: Моск. обл. г.Дмитров
Сообщений: 45
Ну вот, я опять пропустил интересное . Ребят, а вы вообще, спите хоть иногда
Пройдусь по всему сразу. Может не совсем хронологически...

Сколь миниатюрные устройства (ПК, КПК, МПК ... ), нам бы не описывали футурологи, всегда будет планка, после которой устройством становится просто неудобно пользоваться с помощью МЕХАНИЧЕСКИХ и ТАКТИЛЬНО-СЕНСОРНЫХ примочек ввода (у вывода все таки рамки пошире). Я специально выделил эти слова, что бы не попасть в список, который привел Den1 Такова наша с вами физиология. Есть еще уровень команд мозга, и сейчас уже есть реальные наработки в этой сфере, но тогда вообще встает вопрос, а нужна ли конечному автомату управляющая ОС?
В общем, можно миниатюризировать все до предела, но компьютер, в нашем сейчас понимании, уже реализован на минимальной планке смартфон/кпк.

Слова Den1:

2. ПМК - это 2ГГц PM 2ГБ RAM Centrino размером с бумажник, меньше - в кармане куртки.
3. На такую систему можно установить и оффтопик и любой стандартный Линукс дистрибутив. Я не видел вживую Flayer Midget - это может быть пустым, но примерно через год системы такого уровня все равно появятся.
Короче ПМК, как я его вижу, это действительно полноценный рабочий х86, который всегда с тобой.


Батенька, мы уже опоздали... Все уже сделано за нас... Что сейчас еще можно сделать:
1) Нам сейчас не надо проектировать ни ОС-21 ни ОС-22.
2) Мы должны максимально точно воспроизвести устройства, которые заменят, сегодняшние ПК на всех фронтах лет эдак через 20-40.
(А вот так вопрос еще никто не ставил. Если мы решим эту задачу, то мы сможем спроектировать и ОС-21(22), а то получается что выдумываем "что-то" сами не зная для чего.
Хоть закон Мура по настоящему не существует (это миф), но Гордон Мур действительно сделал прогноз, который был верен несколько десятилетий подряд, что мешает НАМ делать такие же прогнозы? И соответственно, корректировать свои действия?
Ну вот, хотел пройтись по всем нитям, но как всегда зациклился на одной мысли... И та растекается донельзя... Надеюсь, что смог перевести нить обсуждения в нужное русло. Ваши комментарии?

Наверх
Freeman
Воскресенье 10.07.2005 03:34
ID пользователя #3
Зарегистрирован: Четверг 01.07.2004 14:57
Сообщений: 207
brasset написал(а) ...
Гордон Мур действительно сделал прогноз, который был верен несколько десятилетий подряд, что мешает НАМ делать такие же прогнозы?

"Исключение WinFX из Longhorn может привести к смерти Linux"
Наверх
den1
Воскресенье 10.07.2005 04:25
ID пользователя #363
Зарегистрирован: Вторник 05.07.2005 16:47
Местонахождение: Россия. Москва.
Сообщений: 151
brasset написал(а) ...
Такова наша с вами физиология. Есть еще уровень команд мозга, и сейчас уже есть реальные наработки в этой сфере.

Пока кратко... Я приводил довольно интересную информацию по поводу вариантов BMI на linux.org.ru (domenick там мой ник):
den1 [url написал(а) ...
http://www.linux.org.ru/jump-message.jsp?msgid=926062[/url]]
Я предлагаю к эволюционированию тех же GUI относиться спокойно (да и не только к этому ). Само понятие GUI вполне может быть преобразовано с течением времени к BUI , например, (Brain User Interface) и так далее. Неплохая передача была по Discovery недавно: комментарии и показ работы специалистов (не наших, к сожалению естественно, (что характерно для современного _нашего_ состояния... нда...)). Управление имитатором военного самолета при помощи анализа активности мозга. Женьщина, лет 50, научный сотрудник... говорит, вот, научицца очень просто, легче, чем машиной управлять..., просто привыкаешь... потом на автомате..., сидит себе спокойно, пару проводочков к голове приклеено ... кабина вправо-влево наклоняется... Другой, курсор по экрану во всю возюкает... Третья дифченка... лет 20... в компьютерной игре "со снежной горки съезжает..., примерно как tux racing...

На создание приложения может уходить слишком много времени... столько, что за время создания может появиться следующее поколение программ...

,ну и на моей конференции еще немного есть http://www.teleology.ru/cgi-bin/ib1/ikonboard.cgi?act=ST;f=2;t=13


Наверх
Сайт
batu
Воскресенье 10.07.2005 15:43
ID пользователя #5
Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22
Я считаю (и работаю над этим весьма успешно) что в новой ОС все файлы должны быть одного формата. Все приложения должны управлятся одинаково. Дальнейшее развитие не в объектно-ориентированом, в аспектно-ориентированом языке. Здесь тормозит архитектура машин. Нужна более прогресивная система адресации данных, и аппаратная поддержка событий. Все наработки у меня есть. Но, вот что с ними делать дальше? Кому интересно могу остановится более подробно над каждым пунктом.
Наверх
Сайт
batu
Понедельник 11.07.2005 16:51
ID пользователя #5
Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22
Да. Еще от процессора нужно програмирование распределение процессоров, программируемые алгоритмы распределеня кэш, проверка типов и провернка на наличие значения.
Наверх
Сайт
captain cobalt
Четверг 14.07.2005 08:01

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
batu написал(а) ...
проверка типов
Проверка типов может быть практически полностью выполнена во время компиляции и компоновки, и не потреблять ресурсов во время исполнения.
batu написал(а) ...
проверка на наличие значения
Ссылочный тип данных. Проверка на наличие значения - проверка ссылки на NIL. Можно использовать механизмы аппаратной защиты памяти, чтобы перехватывать обращение по нулевому адресу. Использовать сборку мусора, чтобы избежать утечек памяти и висящих указателей. Для тяжёлых случаев - untraced poiner.
Что в результате получается?
Вах, да это же Вluebottle.
batu написал(а) ...
Еще от процессора нужно програмирование распределение процессоров
А как работают сейчас системы на мультипроцессорах?
batu написал(а) ...
программируемые алгоритмы распределеня кэш
В настоящее время имеются: загрузка данных в кэш (prefetch), выгрузка строки кэша (write-back & invalidate), сохранение напрямую в память минуя кэш (non-temporal store).

Что ещё нужно?

Нужен ли монопольный контроль над кэшем?
Как насчёт вытесняющей квази-параллельности?
В популярных процессорах кэш прозрачно совместно используется параллельными задачами.
Следует ли кэш добавить к контексту задачи?
Типичный объём кэша уже измеряется мегабайтами.
Следует ли выгружать / загружать его при каждом переключении задач?
Повысит ли это производительность?
batu написал(а) ...
Я считаю (и работаю над этим весьма успешно) что в новой ОС все файлы должны быть одного формата.
В старой ОС Unix все файлы одного формата - "неструктурированный поток байт".
batu написал(а) ...
Все приложения должны управлятся одинаково.

Что такое "приложения"?
Что такое "управляться"?
Что такое "одинаково"?

Дополнительные вопросы (если имеют смысл):

Что такое "не-приложения"?
Что такое "не-управляться"?
Что такое "не-одинаково"?
batu написал(а) ...
Дальнейшее развитие не в объектно-ориентированом, в аспектно-ориентированом языке.
А как называется этот язык?
В чём заключается развитие?
Годится ли язык Лисп, которому около 50 лет?
batu написал(а) ...
Здесь тормозит архитектура машин. Нужна более прогресивная система адресации данных
Также нужно изучать учебники по структурам данных.
batu написал(а) ...
и аппаратная поддержка событий
Аппаратные прерывания.
Любая форма асинхронных событий требует разрыва конвеера.
Конвеерное исполнение кода - основа высокой производительности процессоров.
Каким образом события повысят производительность?
batu написал(а) ...
Все наработки у меня есть. Но, вот что с ними делать дальше?
Прежде всего избавиться от мненя, что нечто должно быть аппаратно.
Наоборот, всё должно быть программно.
Процессоры P4 даже код x86 не исполняют аппаратно, а транслируют в микрокод с другой архитектурой, который затем исполняют.
Необходима ОС, которая будет эффективно работать на сотне миллионов существующих x86 машин.
batu написал(а) ...
Кому интересно могу остановится более подробно над каждым пунктом.
Интересно.
<span class='smallblacktext'>[ Редактирование четверг 14.07.2005 08:19 ]</span>

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
batu
Пятница 15.07.2005 01:39
ID пользователя #5
Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22
Сори.. Я наверное слишком много написал в ответ.. И все пропало.. Видимо ответ был длинным. Прошу обратить на это внимание.. ну предепредили бы.. Но зачем же пропадать написанному.
Наверх
Сайт
Roman I Khimov
Пятница 15.07.2005 13:21

ID пользователя #1
Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601
batu, насколько я знаю, здесь нет ограничения на размер сообщения. Ограничение задается только СУБД (64 КБ), но она, если что, просто обрежет сообщение. Кхм. Могу только предложить попробовать повторить.


Греби и улыбайся!
Наверх
Сайт
den1
Суббота 16.07.2005 00:54
ID пользователя #363
Зарегистрирован: Вторник 05.07.2005 16:47
Местонахождение: Россия. Москва.
Сообщений: 151
captain, я тут неспешно продолжаю знакомиться с Bluebottle... и еще... Zonnon. Ты готов поделиться мнением о перспективе возможной ОООС вокруг Zonnon?
Наверх
Сайт
captain cobalt
Суббота 16.07.2005 05:57

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
Bluebottle - это среда исполнения для языка программирования Active Oberon.

Zonnon - это язык программирования, разрабатываемый по гранту Microsoft под платформу dotNET.

После разработки основной части Bluebottle, разработки в области языков программирования были поделены. "Полезные" возможности, например встроенный в язык механизм разработки плагинов, вошли собственно в язык Active Oberon. А всякие "лишние ненужные" возможности, например взаимодействие между активными объектами по протоколам, описанным в EBNF, пошли в Zonnon, к Microsoft. Zonnon - специфический язык, разрабатываемый специально с учётом ограниченных возможностей платформы dotNET. Многим оберонщикам не нравится Zonnon.

Bluebottle - это расширяемая система. В том числе можно расширять и среду исполнения. Например, язык Java содержит средства структурной обработки исключений, который требует поддержки среды исполнения, и которой нет в основном Bluebottle (потому что их нет в языке Active Oberon). Но в проекте Jaos необходимое расширение было написано, и используя его, код на Java может поддерживаться в полном объёме.

Вывод: "ОС чисто на Zonnon" не имеет особого смысла. Bluebottle может быть довольно легко расширена для поддержки кода Zonnon, а переписывание Bluebottle на Zonnon ничего не даст.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
Переход на страницу  1 2 3 [4] 5 ... 10 11 12  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.