Ну он не мой. Я его перевожу (я же не Sergio). По крайней мере ещё две статьи будут переводом. А после уже буду соавтором. Собсвенно даже третья часть целиком не дописана. Хотя половина третьей части по объёму примерно равна полной второй части.
На самом деле даже просто переводить это достаточно круто. Я пару месяцев разбирался с материалами и потом некоторое время ждал собственную малинку. После этого уже решил переводом заниматься.
Как вы думаете, насколько реально написать подобное для: ARM Cortex M4?
Вполне себе можно. В некотором смысле даже проще. Часть материала пересекается. Но периферия разумеется другая будет. На мой взгляд в данном случае следует выделять большее количество времени железной части. Ну и это будет не ОС общего назначения, а ОС реального времени. Немного разные подходы.
Будет железка какая с Cortex-M — смогу заняться. Но сначала надо с Cortex-A разобраться. А это достаточно надолго.
У меня на ближайшее будущее примерно следующий план по этому всему:
Допереводить курс.
Дописать недостающие главы в курсе (половина третьей и четвёртая часть)
Конвертировать курс в stand-alone версию (чтоб её было легче дополнять)
Добавить инфы про периферию (фреймбуфер, USB, SDIO).
А дальше уже по ситуации.
У меня есть задумка про целый цикл, посвященный графике. Что-то вроде "полный графический стек с нуля". Сначала тоже относительно простое введение про фреймбуфер и софтварную графику. И плавно перейти на OpenGL ES и OpenVG. Только не как обычно, а прям реально с нуля. Т.е. открываем доки по малинке, открываем спецификацию по OpenGL и запиливаем это всё.
Почему отдельным циклом? Так можно частично отвязать один курс от другого. И будет не сильно важно, с какого начинать.
Чем будет полезен такой курс? В таком виде будет полное понимание работы графических процессоров в контексте тех же смартфонов. Достаточно ценные и полезные знания. Например после такого появится навык оптимизации графики. Не в слепую, а с полным пониманием того, что на что влияет. Я видел разные курсы. Одни суть туториалы по готовому API, другие — софтварная реализация этого всего. А всего вместе в одном месте не видел (может я просто не слишком хорошо искал).
Но вообще для меня это всё — самообучение. Точнее попытка сделать собственные знания более последовательными и цельными. Хочешь научиться чему либо — старайся научить этому других.
Фильм не смотрел. Книжку читал. Нет, это художественное преувеличение.
Я видел вполне себе реальные примеры и мне есть с чем сравнить. Я могу сказать, что:
Видимый вред есть.
Но только если знаешь, на что смотреть.
Психику может выжигать.
Но без сильной предрасположенности это не будет заметно на общем фоне.
Реальность как всегда немного другая. Многолетнее употребление амфетаминов сильно ухудшит качество жизни и сократит её срок. Но скажем за полгода человек в зомбака не превратится. Хотя проблемы со здоровьем таки дадут о себе знать, внешне это будет не сильно заметно. При чём половина проблем придёт как раз от "я похудел на 20-40 кг".
некоторые из которых заявляли о помощи в потере веса, и обнаружила девять БАДов, содержащих искусственные соединения, похожие на амфетамины.
Эти по крайней мере должны работать. Подобные соединения действительно обладают мощным эффектом по части блокирования аппетита. Правда количество побочек от такого будет зашкаливать.
Это не ПОДРОБНО. Это даже не подробно. Это даже на общие идеи не тянет. ПОДРОБНО — это примерно под 100 страниц A4 (я по минимуму беру). подробно — тоже принимается. Это примерно 20-30 страниц. Примерно на хорошую годную публикацию.
Чувствую, что модераторы не похвалят за картинку, но мне лично все равно.
А мне кажется, что гифка забавная и очень неплохо характеризует ситуацию. Вот ещё одна такая:
задача микроядра — организовать общение между процессами
А ещё изолировать процессы друг от друга. Микроядро тоже занимается этим.
Фишка раста — статическая верификация всего что только можно, он в этом впереди многих языков.
Вы не понимаете, какие гарантии даёт Rust. Вы читали книгу версии 2 и номикон? Перечитайте.
Нужно бинарное представление сигнатур, типа этого
Я не понял намёка.
Компилятор раста проверяет типы. Будет ошибка компиляции.
А что с кодом на Няшном? Или на Крестах? Или на асме? Или на хачкеле? Или на [любой другой ЯП]? Я тоже люблю заниматься таким бесполезным делом, как переписывание с одного ЯП на другой, но желания переписать абсолютно всё у меня както не возникает.
Мой посыл следующий: за вас это пилить никто не будет. Это будет верно даже если это хорошая годная идея. Пока я вижу только троллинг или чунибьё. Это не мешает мне с вами разговаривать. В конце концов это набивает количество комментов к статье.
С uuid тоже не понел. Что это даёт кроме того, что эти uuid надо генерировать зачем-то?
А у меня в мыслях есть одна такая, которая желает зарезать возможности пользователя на столько, насколько это вообще в принципе возможно. Желательно без потерей производительности. И при этом всё предоставить минимально необходимый функционал.
Мне жаль вас разочаровывать, но я ничего не понял. Напишите ПОДРОБНОЕ описание того, чего вы хотите запилить. А пока держите эту тематическую картинку:
Это называется "модули ядра". Только для доверенного кода. Т.е. только то, что целиком контролируется. Все third-party драйвера яб вынес в пользовательское пространство (как в микроядрах).
типизированные бинарники
Они и так типизированы все. См. спецификацию ELF например. Или что-то ещё?
система типов раста на уровне ОС, гарантии раста между исполняемыми файлами
Нет идей, зачем это нужно. Наоборот интерфейс должен быть на столько простым, на сколько это возможно. Но может быть я опять же не до конца понимаю, что под этим понимается.
А вот это годно. Есть какие либо мысли в развитие этой темы? Просто другие названия команд точно не подойдут. Что-то в замен концепции командной строки?
Это исследовательская задача, которая требует не сыкунов с границами в мышлении и теплым местечком в корпорации с бесплатной едой и абонементов на фитнес. Такая задача требует новых бунтарей и пионеров.
Отлично же! Проведите такое исследование. Я уже жду статью по этой теме и с удовольствием её почитаю.
Ну он не мой. Я его перевожу (я же не Sergio). По крайней мере ещё две статьи будут переводом. А после уже буду соавтором. Собсвенно даже третья часть целиком не дописана. Хотя половина третьей части по объёму примерно равна полной второй части.
На самом деле даже просто переводить это достаточно круто. Я пару месяцев разбирался с материалами и потом некоторое время ждал собственную малинку. После этого уже решил переводом заниматься.
Вполне себе можно. В некотором смысле даже проще. Часть материала пересекается. Но периферия разумеется другая будет. На мой взгляд в данном случае следует выделять большее количество времени железной части. Ну и это будет не ОС общего назначения, а ОС реального времени. Немного разные подходы.
Кстати можно не M4, а M33. ARMv7 против ARMv8. Но вообще вот: https://en.wikipedia.org/wiki/ARM_Cortex-M
Будет железка какая с Cortex-M — смогу заняться. Но сначала надо с Cortex-A разобраться. А это достаточно надолго.
У меня на ближайшее будущее примерно следующий план по этому всему:
А дальше уже по ситуации.
У меня есть задумка про целый цикл, посвященный графике. Что-то вроде "полный графический стек с нуля". Сначала тоже относительно простое введение про фреймбуфер и софтварную графику. И плавно перейти на OpenGL ES и OpenVG. Только не как обычно, а прям реально с нуля. Т.е. открываем доки по малинке, открываем спецификацию по OpenGL и запиливаем это всё.
Почему отдельным циклом? Так можно частично отвязать один курс от другого. И будет не сильно важно, с какого начинать.
Чем будет полезен такой курс? В таком виде будет полное понимание работы графических процессоров в контексте тех же смартфонов. Достаточно ценные и полезные знания. Например после такого появится навык оптимизации графики. Не в слепую, а с полным пониманием того, что на что влияет. Я видел разные курсы. Одни суть туториалы по готовому API, другие — софтварная реализация этого всего. А всего вместе в одном месте не видел (может я просто не слишком хорошо искал).
Но вообще для меня это всё — самообучение. Точнее попытка сделать собственные знания более последовательными и цельными. Хочешь научиться чему либо — старайся научить этому других.
Фильм не смотрел. Книжку читал. Нет, это художественное преувеличение.
Я видел вполне себе реальные примеры и мне есть с чем сравнить. Я могу сказать, что:
Реальность как всегда немного другая. Многолетнее употребление амфетаминов сильно ухудшит качество жизни и сократит её срок. Но скажем за полгода человек в зомбака не превратится. Хотя проблемы со здоровьем таки дадут о себе знать, внешне это будет не сильно заметно. При чём половина проблем придёт как раз от "я похудел на 20-40 кг".
Эти по крайней мере должны работать. Подобные соединения действительно обладают мощным эффектом по части блокирования аппетита. Правда количество побочек от такого будет зашкаливать.
Показательный расстрел. Приурочено к попыткам блокировок Телеграмма.
Действительно. Yuri's Night звучит как что-то плохое. Хм.
11 апреля ещё и день анимешника в России.
Это не ПОДРОБНО. Это даже не подробно. Это даже на общие идеи не тянет. ПОДРОБНО — это примерно под 100 страниц A4 (я по минимуму беру). подробно — тоже принимается. Это примерно 20-30 страниц. Примерно на хорошую годную публикацию.
А мне кажется, что гифка забавная и очень неплохо характеризует ситуацию. Вот ещё одна такая:
А ещё изолировать процессы друг от друга. Микроядро тоже занимается этим.
Вы не понимаете, какие гарантии даёт Rust. Вы читали книгу версии 2 и номикон? Перечитайте.
Я не понял намёка.
А что с кодом на Няшном? Или на Крестах? Или на асме? Или на хачкеле? Или на [любой другой ЯП]? Я тоже люблю заниматься таким бесполезным делом, как переписывание с одного ЯП на другой, но желания переписать абсолютно всё у меня както не возникает.
Мой посыл следующий: за вас это пилить никто не будет. Это будет верно даже если это хорошая годная идея. Пока я вижу только троллинг или чунибьё. Это не мешает мне с вами разговаривать. В конце концов это набивает количество комментов к статье.
С uuid тоже не понел. Что это даёт кроме того, что эти uuid надо генерировать зачем-то?
А у меня в мыслях есть одна такая, которая желает зарезать возможности пользователя на столько, насколько это вообще в принципе возможно. Желательно без потерей производительности. И при этом всё предоставить минимально необходимый функционал.
А хотя нет. Можно чутка побеседовать.
Опишите, как вы будете реализовывать гарантии того, что пользователь не может нарушать эти гарантии.
Мне жаль вас разочаровывать, но я ничего не понял. Напишите ПОДРОБНОЕ описание того, чего вы хотите запилить. А пока держите эту тематическую картинку:
Запилю, если не будет лень. Может что-то похожее.
Предполагается, что ОС сможет выполнять любые проги. В том числе и bash. Это полностью на совести клиента.
Зачем? Профита никакого. Про производительность можно говорить, когда есть бенчмарки. И не секундой раньше.
Что? Всмысле ПОДРОБНО.
Можно впихнуть раздел в ELF с информацией об этом.
Пользователь может менять бинарник любым доступным способом. Ваши действия?
Почитал ссылку. Закрываю тему до появления чего-то похожего на хотяб спецификацию. Но лучше сразу демку.
Когда будет бенчмарк, тогда и поговорим.
bash менять не нужно. Пусть себе лежит. У нас кстати нет чего либо похожего. Тупо интерактивная строка.
Яб tcl взял.
Как на счёт wasm? У меня есть идея запилилить песочницу с wasm в качестве байткода и чем-то вроде cloudabi в качестве набора системных вызовов.
Это называется "модули ядра". Только для доверенного кода. Т.е. только то, что целиком контролируется. Все third-party драйвера яб вынес в пользовательское пространство (как в микроядрах).
Они и так типизированы все. См. спецификацию ELF например. Или что-то ещё?
Нет идей, зачем это нужно. Наоборот интерфейс должен быть на столько простым, на сколько это возможно. Но может быть я опять же не до конца понимаю, что под этим понимается.
Неа. Пока особых проблем со следующей частью не предвидится.
А вот это годно. Есть какие либо мысли в развитие этой темы? Просто другие названия команд точно не подойдут. Что-то в замен концепции командной строки?
Отлично же! Проведите такое исследование. Я уже жду статью по этой теме и с удовольствием её почитаю.