Много ли бреда в идее?
Модератор: Duncon
Компилировать каждое приложение, утилиту, или ннструмент в специализированный аппаратный модуль, в виде которого и выпускать. Нужна системная функция? Эйси, обращаемся к ней по внутренней сети. Комп по сути будет кластерным, но каждый его узел специализирован для одного приложения. Приложение может самостоятельно хранить логи и конфигурационные файлы во внутренней твердотельной долговременной памяти, игры могут самостоятельно хранить в ней таблицу рекордов и даже файлы игровых "отгрузок", в которых записано, чего в неё наиграли за каждого персонажа и где каждый остановился. А текстовый процессор, например, пользовательские файлы размещает на винчестере, обращаясь к нему через систему. Во-первых желаемая структура дерева каталогов для размещения таких файлов несколько сложнее одного каталога с файлами-слотами, во вторых сами файлы имеют смысл вне конкретного текстового процессора, а в-третьих их количество и размеры слабо предсказуемы, поэтому на основной винчестер, или такой же SSD. А игровые "отрузки" не имеют смысла вне конкретной игры, их количество можно без особого вреда для качества игрового приложения ограничить, размеры этих файлов вполне предсказуемы исходя из значимых атрибутов самого игрового мира и разветвлённое дерево каталогов для них не нужно, в крайнем случае каталог с каталогами игроков и там уже слоты для каждого файла. Поэтому их можно хранить и в самом приложении. Но можно и на основном винчестере/SSD. И логи и таблицы рекордов можно и на основной винчестер/SSD складывать. И всякие там ini-файлы и ключи реестра тоже. Где хранить данные, имеющие смысл только в самом приложении, - это на усмотрение его разработчиков. Но кроме данных, с которыми оно поставляется, эти только внутри. Система контролирует весь внутренний трафик, отвечает за включение и выключений приложений, вызовы приложениями друг друга проходят через систему, она же отвечает за весь обмен данными между приложениями. На сколько всё это бредово? Мне самому кажется, что полностью, но всё таки хочу узнать ваше мнение.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
На 70% совпадает с программной реализацией XBOX 360
It's a long way to the top if you wanna rock'n'roll
То есть? Каким боком здесь программная реализация? Речь о том, что пишешь вроде как программу, но компилируешь в комбинацию прошивки, микрокода и внутренностей ядра процессора, дополняешь образ количеством ядер и размерами ОЗУ, ПЗУ/ППЗУ и SSD, потом серийно (возможно мелкосерийно) выпускаешь этот девайс, распространяешь его, потом хозяин/админ целевой машины ставит его внутри системника. В таком виде приложение. Когда задача - физически напечатать текст на бумаге, то решение в принципе одно - подключить аппаратное устройство. Но даже оно обычно имеет программный драйвер. А здесь речь о том, что и текстовый процессор, СУБД и игра реализуются также. XBOX - разве одно устройство на одну игру? Нет. Здесь же речь о дальнейшем развитии идеи картриджей для какой нибудь денди, или сеги, только этот "картридж" не только хранит, но и исполняет игру и в него же можно сохранить и таблицу рекордов, и информацию о том, сколько у персонажа денег, маны и здоровья, докуда конкретно он дошёл, какие миссии выполнил, какие предметы у него в рюкзаке, какое у него есть оружие и доспехи, сколько у оружия и доспехов осталось прочки, сколько у персонажа каких боеприпасов, какие миссии у него в процессе. И при этом он не устанавливается чтоб поиграть и потом вытаскивается, а установлен постоянно вместе с другими подобными, а пользователь выбирает, какой из них запустить, с интерфейса системы, + они ещё могут обмениваться данными. Мне кажется, что здесь бреда 100%, причём, отборного. Но хочется вашего подтверждения.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
Ну допустим мы имеем некий девайс на PCI Express, который представляет собой игровой модуль, способный только лишь на запуск конкретной игры... скажем GTA 5. Этот игровой модуль будет на базе какой то мощной сверхскоростной шине данных, которая обеспечит взаимодействие подключенных модулей. Один вопрос - зачем все это? Какие плюсы/минусы? Какова будет стоимость одной такой игры/приложения/ОС ?
It's a long way to the top if you wanna rock'n'roll
Ну зачем - это очевидно. Сокрытие даже исполняемого кода отчуждаемого приложения.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
Ну а чё, интересная идея делать приложения в виде отдельных контроллеров. Наверно там как минимум повысится устойчивость к вирусам. Но всё это явно дорого, поэтому не всё без разбора надо "зашивать" в железо.
*unix архитектуры устойчивы к вирусам - программное решение..
[syntax=Delphi] [/syntax]
Ну это да, про юникс/линукс не подумал.
Живность то здесь при чём?
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.
Реализация как раз программно-аппаратная, а не чисто аппаратная, все модули шьются кодом, который и управляет процессорами приложений. И не всегда даже в ПЗУ, код может храниться и в долговременной, но всё таки многократно перезаписываемой памяти модулей. Но при этом можно оптимизировать систему команд без оглядки на совместимость с грузом наработанного софта, а в код чужого приложения нельзя без разрушения заглянуть ни дебагером, ни hex-редактором, ни каким либо иным инструментом.Avatar-Z писал(а):Ну а чё, интересная идея делать приложения в виде отдельных контроллеров. Наверно там как минимум повысится устойчивость к вирусам. Но всё это явно дорого, поэтому не всё без разбора надо "зашивать" в железо.
Писать можно на чём угодно, но зачем же так себя ограничивать? Пиши на c.