Я выражаю сомнение в необходимости культивирования слепого набора. Это не фундаментальный навык. Скорость работы с клавиатурой вообще и терминалом в частности достигается практикой, практикой и еще раз практикой. Вообще всегда считал, что слепой набор — это такой факультатив для «задротов». (Другое дело, если человек ищет на клавиатуре букву тридцать секунд. Тут слепой набор можно дать просто как упражнение.)
Есть куча гораздо более интересных вещей, которые можно дать школьнику. Главное ведь заинтересовать. А там и навык работы с клавиатурой подтянется.
Насколько хороша повторяемость этого эксперимента? Я имею ввиду, получу ли я схожие результаты, если прогоню еще 100 000 000 пакетов? Может это просто дикая дисперсия?
Интерфейсы, протоколы, расширения и т.д.… Ведь это всё подмножество наследования классов в общем и множественного наследования в частности.
Зачем отказываются от общего механизма (множественного наследования), чтобы затем придумывать частные решения той же задачи, плодя сущности на ровном месте?
Не лучше ли просто сказать: «Вот множественное наследование — это сложный и мощный инструмент, которым ты, падаван, можешь и порезаться. Но изучив его один раз, ты изучишь его десять раз, и сможешь применять тысячей возможных способов.»
Зачем весь этот зоопарк технологий и разномастных названий одного и того же?
Интересна именно ситуация со вложенными драйверами, когда каждый драйвер предоставляет блокирующие операции. Получается, что первый драйвер должен для выполнения блокирующей операции несколько раз вызвать блокирующую операцию следующего драйвера. Чего as is в условии «лёгких потоков» он сделать не может, ибо не помнит, на чем он на прошлой итерации остановился.
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
А удалось использовать легковесные потоки с ссылающими друг на друга драйверами устройств? Ну, допустим, когда драйвер block_device флешпамяти использует драйвер spi и так далее?
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
Строго говоря, возможны разные реализации, но таки обычно директорий представлен специальным типом файла и описан в полноправной inode. Так что жёсткая ссылка на него допустима так же, как и на любой другой файл.
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
У меня вопрос о вашем бэкграунде (в части знаний).
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?
Строго говоря, ipv6 не ломает концепцию NAT. NAT можно перевести на ipv6 ровно в том виде, в котором он сейчас существует.
Впрочем, наверняка можно придумать более правильные механизмы фильтрации. Тоесть, реализовывать фильтрацию трафика не лишая внутреннюю машину глобального ip.
Процесс, в любом случае, необратим… Так что перейдём все, никуда не денемся.
50% до конца десятилетия — верится с трудом. График очень красивый. Похож на правду — по идее — колебательный процесс с небольшими флуктуациями, похож на процессы в ТАУ. Если это действительно так, процесс ускорится, но не на много. 2022, ИМХО, более реальный прогноз для 50%. Дальше рост начнет замедляться. Где-то к 2032 от ipv4 остануться проценты.…
Есть куча гораздо более интересных вещей, которые можно дать школьнику. Главное ведь заинтересовать. А там и навык работы с клавиатурой подтянется.
Но, это так… ИМХО.
Интерфейсы, протоколы, расширения и т.д.… Ведь это всё подмножество наследования классов в общем и множественного наследования в частности.
Зачем отказываются от общего механизма (множественного наследования), чтобы затем придумывать частные решения той же задачи, плодя сущности на ровном месте?
Не лучше ли просто сказать: «Вот множественное наследование — это сложный и мощный инструмент, которым ты, падаван, можешь и порезаться. Но изучив его один раз, ты изучишь его десять раз, и сможешь применять тысячей возможных способов.»
Зачем весь этот зоопарк технологий и разномастных названий одного и того же?
А opengl здесь и работает…
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?
Впрочем, наверняка можно придумать более правильные механизмы фильтрации. Тоесть, реализовывать фильтрацию трафика не лишая внутреннюю машину глобального ip.
50% до конца десятилетия — верится с трудом. График очень красивый. Похож на правду — по идее — колебательный процесс с небольшими флуктуациями, похож на процессы в ТАУ. Если это действительно так, процесс ускорится, но не на много. 2022, ИМХО, более реальный прогноз для 50%. Дальше рост начнет замедляться. Где-то к 2032 от ipv4 остануться проценты.…
Ну… Гадание по графику…