В целом 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__.
В целом, ввести дополнительные проверки можно, но я все-же полагаю, что это не задача библиотеки контролировать валидность входных данных. Можно понаписать множество тестов и все равно не покрыть всю область возможных ошибок.
Собственно, изначально я делал что-то подобное. Счел излишним. Выпилил всё, оставил только логику.
В целом сама по себе идея универсальных ссылок неплоха.
В теории это может разрубить гордиев узел html+javascript, который человечество навязало и уже двацать лет развязать не может.
При широком внедрении этой технологии браузер становится одним из, но не единственным средством хождения в интернет. Можно будет делать альтернативные куски сети вплоть до бинарного вэба, и что более всего ценно, эти куски сети будут связаны воедино технологией универсальных ссылок. Грубо говоря, в ссылке будет содержаться инфа на тему того, каким абстрактным браузером надо этот кусок сети открывать.
В целом 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__)`.
Жаль, у меня нет хорошей задачи под отладку.
Я это обмозгую. Спасибо.
В целом, ввести дополнительные проверки можно, но я все-же полагаю, что это не задача библиотеки контролировать валидность входных данных. Можно понаписать множество тестов и все равно не покрыть всю область возможных ошибок.
Собственно, изначально я делал что-то подобное. Счел излишним. Выпилил всё, оставил только логику.
В теории это может разрубить гордиев узел html+javascript, который человечество навязало и уже двацать лет развязать не может.
При широком внедрении этой технологии браузер становится одним из, но не единственным средством хождения в интернет. Можно будет делать альтернативные куски сети вплоть до бинарного вэба, и что более всего ценно, эти куски сети будут связаны воедино технологией универсальных ссылок. Грубо говоря, в ссылке будет содержаться инфа на тему того, каким абстрактным браузером надо этот кусок сети открывать.
Будем наблюдать.