Нельзя не отметить, что нет особой разницы между программой, использующей стандартные либы и программой использующей сторонние библиотеки, использующие стандартные либы. Вы все равно запускаете на машине пользователя код, которому пользователь не может доверять.
Впрочем, стандартизация библиотек идет полным ходом, что обусловленно нормальным эволюционным процессом. Думаю, еще лет двадцать и стандартный набор будет.
Попадание в «Адмнистрирование» произошло из-за того, что я отправил пост в хаб «Хранение данных». Вчитавшись в его описание, понимаю, что это немного о другом хранении данных…
А если старый код остаётся в неизменном виде, но его изменение при поддержке и доработке производятся с применением новых возможностей? Приводит ли такой подход к каким-то затруднениям?
Я выражаю сомнение в необходимости культивирования слепого набора. Это не фундаментальный навык. Скорость работы с клавиатурой вообще и терминалом в частности достигается практикой, практикой и еще раз практикой. Вообще всегда считал, что слепой набор — это такой факультатив для «задротов». (Другое дело, если человек ищет на клавиатуре букву тридцать секунд. Тут слепой набор можно дать просто как упражнение.)
Есть куча гораздо более интересных вещей, которые можно дать школьнику. Главное ведь заинтересовать. А там и навык работы с клавиатурой подтянется.
Насколько хороша повторяемость этого эксперимента? Я имею ввиду, получу ли я схожие результаты, если прогоню еще 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(в широком смысле)…
Впрочем, стандартизация библиотек идет полным ходом, что обусловленно нормальным эволюционным процессом. Думаю, еще лет двадцать и стандартный набор будет.
Есть куча гораздо более интересных вещей, которые можно дать школьнику. Главное ведь заинтересовать. А там и навык работы с клавиатурой подтянется.
Но, это так… ИМХО.
Интерфейсы, протоколы, расширения и т.д.… Ведь это всё подмножество наследования классов в общем и множественного наследования в частности.
Зачем отказываются от общего механизма (множественного наследования), чтобы затем придумывать частные решения той же задачи, плодя сущности на ровном месте?
Не лучше ли просто сказать: «Вот множественное наследование — это сложный и мощный инструмент, которым ты, падаван, можешь и порезаться. Но изучив его один раз, ты изучишь его десять раз, и сможешь применять тысячей возможных способов.»
Зачем весь этот зоопарк технологий и разномастных названий одного и того же?
А opengl здесь и работает…
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…