Pull to refresh

Comments 30

Собрать статистику паттернов работы? И в последствии генерировать код алокатора под конкретный паттерн?

Это нереалистичная идея. Вычислительная сложность огромная. Условия меняются.


Но допустим. Какие параметры мы будем оценивать? Как будем изменять алгоритм в зависимости от того, что получили сбором статистики?

>Это нереалистичная идея. Вычислительная сложность огромная. Условия меняются.
Большинство программ работают линейно, у них всегда есть протоптанный путь на графе условных переходов. Минимумы и максимумы входящих и исходящих данных у конкретного пользователя довольно просто предсказывать.

>Какие параметры мы будем оценивать? Как будем изменять алгоритм в зависимости от того, что получили сбором статистики?
Это исследовательская задача, которая требует не сыкунов с границами в мышлении и теплым местечком в корпорации с бесплатной едой и абонементов на фитнес. Такая задача требует новых бунтарей и пионеров.
Это исследовательская задача, которая требует не сыкунов с границами в мышлении и теплым местечком в корпорации с бесплатной едой и абонементов на фитнес. Такая задача требует новых бунтарей и пионеров.

Отлично же! Проведите такое исследование. Я уже жду статью по этой теме и с удовольствием её почитаю.

Последняя картинка несчастливая, следующую часть можно долго ждать (:

Неа. Пока особых проблем со следующей частью не предвидится.

> cd, pwd, cat, ls.
Зачем еще одна юникс подобная ОС? Если уж писать с нуля, то что то новое. Много проектов осдев пересмотрел, везде одно и тоже.

А вот это годно. Есть какие либо мысли в развитие этой темы? Просто другие названия команд точно не подойдут. Что-то в замен концепции командной строки?

* система типов раста на уровне ОС, гарантии раста между исполняемыми файлами;
* типизированные бинарники;
* запуск кода на safe rust без аппаратной защиты;
www.linux.org.ru/forum/talks/13995742
запуск кода на safe rust без аппаратной защиты

Это называется "модули ядра". Только для доверенного кода. Т.е. только то, что целиком контролируется. Все third-party драйвера яб вынес в пользовательское пространство (как в микроядрах).


типизированные бинарники

Они и так типизированы все. См. спецификацию ELF например. Или что-то ещё?


система типов раста на уровне ОС, гарантии раста между исполняемыми файлами

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

> Это называется «модули ядра»
Я знаю что такое модуль ядра и предлагал другое.

> Они и так типизированы все
Они не типизированны вообще. По ельфу нельзя проверить что функция принимает инт и указатель, а не три флота.

> Нет идей, зачем это нужно
Я же написал: гарантии. Зачем тогда раст нужен, если его гарантии не нужны? Сейчас же, как только другой бинарник, сразу же FFI и unsafe. Интерфейс должен быть простым, но, гораздо важнее что бы он был документированным. Статическая типизация прямо в бинарнике — часть документации. Это декларация протокола, которую может проверять ОС, почему бы нет?
Я знаю что такое модуль ядра и предлагал другое.

Что? Всмысле ПОДРОБНО.


По ельфу нельзя проверить что функция принимает инт и указатель, а не три флота.

Можно впихнуть раздел в ELF с информацией об этом.


Я же написал: гарантии.

Пользователь может менять бинарник любым доступным способом. Ваши действия?

Можно впихнуть раздел в ELF с информацией об этом.

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

Ваш пользователь крут. А еще пользователь может разбить компьютер молотком. ОС и от этого должна защищать? Я би предложил такое: пользователь ставит пакеты из репозитория или стора, бинарники подписанны и менять их нельзя. В идеале, бинарники вообще содержат не машинный код, а некоторый байткод, по которому можно валидировать type-safety, который компилируется во время установки пакета.

Мне жаль вас разочаровывать, но я ничего не понял. Напишите ПОДРОБНОЕ описание того, чего вы хотите запилить. А пока держите эту тематическую картинку:


Отвечу в одном посте.

Чувствую, что модераторы не похвалят за картинку, но мне лично все равно.

Смотрите: задача микроядра — организовать общение между процессами. Когда общение идет по фиксированному протоколу — оно безопасно и надежно. Когда общение — это jmp на адресс, у нас нету гарантий, компилятор не может проверить типы и все, приплыли, раст не дает ничего. Фишка раста — статическая верификация всего что только можно, он в этом впереди многих языков. Но ОС ему мешает.

А теперь конкретика, как я это вижу. Интерфейс — это список сигнатур функций, он характеризуется своим UUID, ОС держит список интеррфейсов и соответствующих UUID. Нужно бинарное представление сигнатур, типа этого developer.apple.com/library/content/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html что бы можно было сохранять это. Каждый файл с машинным кодом декларирует интерфейсы и зависит от интерфейсов, соответствующие UUID хранятся в хедере. Ядро, когда грузит бинарник, грузит зависимости, если нужно. Конечно же, программист генерирует UUID для своих интерфейсов. Когда меняется API, UUID тоже меняется.
(Всюду UUID можно заменить на человекочитаемое имя с версией, это уже по вкусу).

Опишите, как вы будете реализовывать гарантии того, что пользователь не может нарушать эти гарантии.

Компилятор раста проверяет типы. Будет ошибка компиляции.

Если же юзер может модифицировать бинарник руками и у него декларация (UUID) не сходится с тем что внутри — это его проблема. Он так же может и «rm -Rf /» сделать, и вообще, использовать молоток.

Это не ПОДРОБНО. Это даже не подробно. Это даже на общие идеи не тянет. ПОДРОБНО — это примерно под 100 страниц A4 (я по минимуму беру). подробно — тоже принимается. Это примерно 20-30 страниц. Примерно на хорошую годную публикацию.


Чувствую, что модераторы не похвалят за картинку, но мне лично все равно.

А мне кажется, что гифка забавная и очень неплохо характеризует ситуацию. Вот ещё одна такая:



задача микроядра — организовать общение между процессами

А ещё изолировать процессы друг от друга. Микроядро тоже занимается этим.


Фишка раста — статическая верификация всего что только можно, он в этом впереди многих языков.

Вы не понимаете, какие гарантии даёт Rust. Вы читали книгу версии 2 и номикон? Перечитайте.


Нужно бинарное представление сигнатур, типа этого

Я не понял намёка.


Компилятор раста проверяет типы. Будет ошибка компиляции.

А что с кодом на Няшном? Или на Крестах? Или на асме? Или на хачкеле? Или на [любой другой ЯП]? Я тоже люблю заниматься таким бесполезным делом, как переписывание с одного ЯП на другой, но желания переписать абсолютно всё у меня както не возникает.


Мой посыл следующий: за вас это пилить никто не будет. Это будет верно даже если это хорошая годная идея. Пока я вижу только троллинг или чунибьё. Это не мешает мне с вами разговаривать. В конце концов это набивает количество комментов к статье.


С uuid тоже не понел. Что это даёт кроме того, что эти uuid надо генерировать зачем-то?

Что то лень писать 100 страниц :)

А ещё изолировать процессы друг от друга. Микроядро тоже занимается этим.
Да. Но виртуальные адрессные пространства — не единственный способ сделать это.

А что с кодом на Няшном? Или на Крестах? Или на асме? Или на хачкеле? Или на [любой другой ЯП]?
Все заработает. Любой другой ЯП предоставляет что то вроде
int main(int argc, char* argv[]) { ... }

Это одна функция, которой соответствует дефолтный интерфейс. Я же всего лишь предлагаю отказаться от динамической типизации здесь. Массив строк — это динамический тип, который превращается в рантайме во что угодно. А нужно что бы функции принимали настоящие типы и ассоциированные лайфтаймы (если раст).
> яб вынес в пользовательское пространство
Ну так одно другому не мешает. Микроядра — это не только отдельные адресные пространства, а в первую очередь изоляция. Для safe rust кода можно статически доказать эту самую изоляцию не используя аппаратную защиту. Это очень в духе раста и c++, проверять статически и не тратить ресурсы в рантайме.
Для safe rust кода можно статически доказать эту самую изоляцию не используя аппаратную защиту.

Зачем? Профита никакого. Про производительность можно говорить, когда есть бенчмарки. И не секундой раньше.

Не нужна причина что бы что-то не делать. Зачем защищать память процесса, если того от чего защищаемся гарантированно не будет?
чего защищаемся гарантированно не будет

Опишите, как вы будете реализовывать гарантии того, что пользователь не может нарушать эти гарантии.

Почитал ссылку. Закрываю тему до появления чего-то похожего на хотяб спецификацию. Но лучше сразу демку.

А хотя нет. Можно чутка побеседовать.

Взамен коммандной строки ничего не хочу. Но язык (bash) поменять нужно, урезанный хаскель взять, например. И сделать ядро, которое будет всего лишь jit компилятором этого языка. Саму ОС писать на нем.
Но язык (bash) поменять нужно

bash менять не нужно. Пусть себе лежит. У нас кстати нет чего либо похожего. Тупо интерактивная строка.


урезанный хаскель взять

Яб tcl взял.


которое будет всего лишь jit компилятором этого языка

Как на счёт wasm? У меня есть идея запилилить песочницу с wasm в качестве байткода и чем-то вроде cloudabi в качестве набора системных вызовов.

> У нас кстати нет чего либо похожего
Подозреваю, что создатели баша думали так же… поначалу. А потом было уже поздно, народ накостылил кучу всего.
> Яб tcl взял.
на вкус и цвет…
> У меня есть идея
нету возражений, пилите.
нету возражений, пилите.

Запилю, если не будет лень. Может что-то похожее.


А потом было уже поздно, народ накостылил кучу всего.

Предполагается, что ОС сможет выполнять любые проги. В том числе и bash. Это полностью на совести клиента.

И в мыслях не было запрещать пользователю что-то выполнять.

А у меня в мыслях есть одна такая, которая желает зарезать возможности пользователя на столько, насколько это вообще в принципе возможно. Желательно без потерей производительности. И при этом всё предоставить минимально необходимый функционал.

Sign up to leave a comment.

Articles