В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще 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 остануться проценты.…
Фактически это о том, что у системы есть некий наиболее вероятный класс состояний, к которому она стремиться при бесконечной последовательности случайных изменений (можно считать, что действует закон больших чисел). Для риса и чечевицы — это мешанина. Для воды и масла — это разделение на две фракции.
То есть, по сути, энтропия — это не о физическом процессе вообще, а о круговороте возможных состояний системы. И теперь мне наконец-то понятна энтропия в информатике.
Может быть вы подскажите, почему операционные системы так долго загружаются. Даже рекордные семь секунд — это же целая вечность во временном масштабе ПО, не говоря уже о загрузке десктопных осей. Что они делают всё это время? На что уходят эти семь секунд?
Митохондрии самостоятельно «принимают решение» о слиянии, или это централизованно управляемый процесс? Бывает так, что клетки в одной части оганизма получают питательных веществ в избытке в то время как в другой части введен режим жесткой экономии?
В каком-то фильме было восстановление звукового ряда по микроколебаниям воды в луже. Сомнительно, учитывая ограничения разрешения камеры, но… В целом о возможности подобных вещей говорят давно.
Я согласен с тем, что общепринятое оформление — это хорошо.
Но есть исключения. Возьмем к примеру sgorsten/linalg (https://github.com/sgorsten/linalg/blob/master/linalg.h). Это плоская библиотека линейной алгебры для с++. Она читаема исключительно благодаря тому, что автор наплевал на общепринятое форматирование.
Постараюсь привести в соответствие с pep8 все, кроме операторов. Они мне пока еще в таком виде нужны.
К сожалению, не знал про этот модуль. Я вообще не так много пишу на питоне. Попробую оптимизировать.
Про pep-8 знаю, хотя подробно его не изучал (опять же, не так много пишу на питоне). Потому форматирование такое, какое мне кажется удобным. Например, не вижу никакого смысла разбивать операторную околесицу по строчкам. Файл станет длинным и сразу же станет очень сложно что-либо в этом файле найти.
`m.update(obj.__module__.encode(«utf-8»))` наверное стоит обернуть. В целом, не вижу особой разницы между этим и каким-нибудь `updatehash_string(m, obj.__module__)`.
Да, если навесить это дело сверху, как подбиблиотеку для тестирования, а не пытаться встроить внутрь, может получиться неплохо.
Жаль, у меня нет хорошей задачи под отладку.
Я, единственно что, использую warning на совпадение if obj.__class__.__repr__ is object.__repr__.
В целом, ввести дополнительные проверки можно, но я все-же полагаю, что это не задача библиотеки контролировать валидность входных данных. Можно понаписать множество тестов и все равно не покрыть всю область возможных ошибок.
Собственно, изначально я делал что-то подобное. Счел излишним. Выпилил всё, оставил только логику.
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще 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 остануться проценты.…
Ну… Гадание по графику…
Фактически это о том, что у системы есть некий наиболее вероятный класс состояний, к которому она стремиться при бесконечной последовательности случайных изменений (можно считать, что действует закон больших чисел). Для риса и чечевицы — это мешанина. Для воды и масла — это разделение на две фракции.
То есть, по сути, энтропия — это не о физическом процессе вообще, а о круговороте возможных состояний системы. И теперь мне наконец-то понятна энтропия в информатике.
Но есть исключения. Возьмем к примеру sgorsten/linalg (https://github.com/sgorsten/linalg/blob/master/linalg.h). Это плоская библиотека линейной алгебры для с++. Она читаема исключительно благодаря тому, что автор наплевал на общепринятое форматирование.
Постараюсь привести в соответствие с pep8 все, кроме операторов. Они мне пока еще в таком виде нужны.
Про pep-8 знаю, хотя подробно его не изучал (опять же, не так много пишу на питоне). Потому форматирование такое, какое мне кажется удобным. Например, не вижу никакого смысла разбивать операторную околесицу по строчкам. Файл станет длинным и сразу же станет очень сложно что-либо в этом файле найти.
`m.update(obj.__module__.encode(«utf-8»))` наверное стоит обернуть. В целом, не вижу особой разницы между этим и каким-нибудь `updatehash_string(m, obj.__module__)`.
Жаль, у меня нет хорошей задачи под отладку.
Я это обмозгую. Спасибо.
В целом, ввести дополнительные проверки можно, но я все-же полагаю, что это не задача библиотеки контролировать валидность входных данных. Можно понаписать множество тестов и все равно не покрыть всю область возможных ошибок.
Собственно, изначально я делал что-то подобное. Счел излишним. Выпилил всё, оставил только логику.