Читайте https://m.habr.com/ru/post/467607/
Кратко — редхат завозит podman & buildah & skopeo для разработки
В опеншифт — докер ими заменяем на cri-O
В кубере — все нормальные люди уже выкидывают докер и ставят containerd/runc
Кто-то идёт дальше и заменяет runc на gVisor или kata.
Для изучения: https://t.me/sre_hamster/70 (там две ссылки на серьёзные исследования)
Где докер пока ещё останется жить — это локальная разработка (но с тем же успехом можно вагрант машины использовать, тем более на виндовых или мак машинах))))
Состояние half-open относится к TCP, в UDP соединениями в состоянии "half-open" можно считаться те, у которых нет обратного трафика. Опять таки в самом UDP нет такого понятия как half-open. QUIC построен поверх UDP, соответственно весь базовый мониторинг должен касаться именно UDP.
Далее у QUIC тоже нет понятия "half-open", есть только "half-closed" и то это относится к потокам в QUIC. Причём потоки в QUIC работают внутри уже установленного соединения (сессии QUIC).
Ок, вам как оператору нужны метрики по QUIC, используйте существующий формат логирования для QUIC и HTTP/3 - qlog. Не поверите, но инструменты мониторинга и отладки уже придуманы или прорабатываются.
Лежит это всё рядом с RFC 9000 в рабочих черновиках и не только. Нужно всего лишь как минимум посмотреть документы рабочей группы QUICWG.
Т.е. существуют документы и по самому протоколу, по вспомогательным элементам протокола таким как QPACK, использование TLS вместо QUIC Crypto, балансировщикам. Есть документы для операторов Applicability & Manageability. Есть документы по расширениям, например тот же qlog, используемый для отладки. Нужна визуализация, не проблема - qvis.
Да QUIC получается более закрытым протоколом по отношению к посредникам, если вы не являетесь условно доверенным лицом одной из стороны обмена данными (а значит у вас вероятно нет доступа ни к qlog ни к другой внутренней и зашифрованной кухне протокола). Но это и к лучшему, а для посредников, обеспечивающих работоспособность соединений и т.д., а не внедрение и прослушивание потока - вся работа остаётся только в рамках IP/UDP.
Я для себя нашёл более спартанское решение линк.
Приземляю по крону раз в час файлик на роутер, а локальный резолвер этот файлик считывает и отдаёт клиентам, и все ноды в сети видят сиииильно меньше рекламы, а заодно меньше шансов что дочь на порнуху напорется или что жена по ссылке невесть какой пройдёт. и не надо ставить на 4 браузера помноженные на 5 устройств (и рут на андроиде ненужен)
Кого готовят наши школы и вузы? Некомпетентных людей.
Ага. Поддерживаю. Потому как я сам именно такой.
У меня школа, ВУЗ, еще один, куча вроде бы практики в бизнесе и разных проектах.
Все это круто, стильно, современно было в России.
Но все это в иной реальности, за границами России, стало полной фигней, шлаком и отстоем.
Инженерное и даже научное образование в России, сами его основы, настолько устарели и настолько отличаются от современных подходов, что даже оторопь берет.
В Польше тоже не лучше, а то и хуже бывает. Так что скорее всего это проблемы именно «возраста знаний» и впитанной в разум методологии, а не страны или социального уклада.
Что же касается стандартов в образовании, в разработке, в производстве — то тут все фигово.
Российские стандарты — чаще всего криво переведенные старые ISO стандарты.
Про «best practice» — еще все намного хуже.
Все это порождает огромную разницу в подходах к работе, совсем разную методологию работ. Ну и результат получается совсем иным.
Переделать себя, свой разум можно. Но приходится начинать с самых азов: от логики Аристотеля к системному подходу, от редукционизма — к холизму, от одномерной классификации — к многмерной, от метафоры работы «на листке бумаги» — к трехмерному проектированию, от восходящих (нисходящих) моделей проектирования — к циклическим, от придумывания новых компонентов — к оптимальному использованию готовых, от изобретательства — к инженерии (и потом обратно), от единственно верного «научного позитивизма» — к множеству научных методов по Лакатосу и Фейерабенду.
И 80% своего времени приходится тратить на постоянное само обучение. Учителя из институтов и школ тут бесполезны и часто вредны. Хотя не менее вредны и маститые практики, которые типа всегда на передовой реальной работы. Институты дают устаревшее и далекое от практики знание, но и практики учат только тому, что помнят или что им нравится, к чему они привыкли на работе.
Тут ведь как: нужно и проверенное на практике знание, и новое, новые методологии, чтобы развивать свои возможности. «Композитная структура знания»: слои твердого, практического знания и слои эластичного, нового знания. Причем одновременно. Тогда будет и эффективность (делаем то, что нужно и вовремя) и эластичность, изменчивость (делаем правильными методами, соответствующим ситуации).
Как-то так.
Understanding map, apply, bind
я думал, что я понял. После прочтения этой статьи я уже нихера не понимаю.
Категория – любой примитивный или составной тип данных...
Я, как очень плохо учивший математику, понял категорию как некое обобщение над множествами, а сами множества являются одной из категорий (Set). А тип, вроде как, как раз укладывается в теорию множеств, как множество всех его допустимых значений. Так тип категория или нет?
Честно говоря, объяснение в порядке "функтор — аппликативный функтор — монада" понятнее, хотя, возможно, я его понял неправильно.
Функтор — отображение морфизма из одной категории в другую. Кстати, о map. После некоторых размышлений мне стало казаться, что название функции означает не то, что она применяет некую функцию к контейнеру (как мы привыкли во всех языках, где есть map), а именно отображение функции в другую категорию. Например, отображает морфизм "+" в категории чисел, в категорию "Maybe чисел". Мне это (либо очень очевидное, либо очень неправильное) понимание пришло в голову, если рассмотреть сигнатуру не как привычную функцию с двумя аргументами map(f, container) -> container, а как каррированную:
fmap:: (a->b) -> fa -> fb
Я прав?
Аппликативный функтор. А вот тут непонятно. Не, смотришь на картинки, на код, это, вроде, тоже самое, но для двух аргументов в контейнерах. Но что-то непонятно. Ладно, вот еще картинки с описанием. Это когда функции в контейнерах и аргументы в контейнерах. Понятнее не стало, да еще и не совпадает.
Монада. Такая штука, которая, в отличие от функтора, умеет работать не только с функциями a -> b, но и a -> m b:
bind :: m a -> (a -> m b) -> m b
Вроде бы, понятно, зачем оно нужно. И понятно, какую проблему (по сравнению с функтором) решает эта сигнатура, на примере тех же Maybe очень понятно. Вот мы имеем цепочку каких-то функций, каждая возвращает Maybe, их друг с другом биндим, все очень круто. А вот почему монада — контейнер? То, что условный Maybe/Option/Nullable итп контейнеры — понятно. Зачем bind при работе с контейнерами — понятно. Но что-то интуитивного понимания нет. И еще почему "монада позволяет описать последовательность" (или что-то в этом роде)?
З.Ы. Монада — тайпкласс. "Что-то" реализующее некие определенные методы является монадой. И "что-то" имеет какие-то данные, реализуем "интерфейс" (в курсе, что это очень грубая аналогия) монады (имея знание о структуре данных), чтобы функции, работающие с монадами, могла работать с нашим типом. Окей. Но с таким же успехом и функтор — контейнер, нет?
Читайте https://m.habr.com/ru/post/467607/
Кратко — редхат завозит podman & buildah & skopeo для разработки
В опеншифт — докер ими заменяем на cri-O
В кубере — все нормальные люди уже выкидывают докер и ставят containerd/runc
Кто-то идёт дальше и заменяет runc на gVisor или kata.
Для изучения:
https://t.me/sre_hamster/70 (там две ссылки на серьёзные исследования)
Где докер пока ещё останется жить — это локальная разработка (но с тем же успехом можно вагрант машины использовать, тем более на виндовых или мак машинах))))
Никакой демонополизации не будет. Цензуры станет больше.
Скриньте и приходите через год, сравним прогнозы.
Состояние half-open относится к TCP, в UDP соединениями в состоянии "half-open" можно считаться те, у которых нет обратного трафика. Опять таки в самом UDP нет такого понятия как half-open. QUIC построен поверх UDP, соответственно весь базовый мониторинг должен касаться именно UDP.
Далее у QUIC тоже нет понятия "half-open", есть только "half-closed" и то это относится к потокам в QUIC. Причём потоки в QUIC работают внутри уже установленного соединения (сессии QUIC).
Ок, вам как оператору нужны метрики по QUIC, используйте существующий формат логирования для QUIC и HTTP/3 - qlog. Не поверите, но инструменты мониторинга и отладки уже придуманы или прорабатываются.
Лежит это всё рядом с RFC 9000 в рабочих черновиках и не только. Нужно всего лишь как минимум посмотреть документы рабочей группы QUICWG.
Есть такие документы как:
RFC 8999 - Version-Independent Properties of QUIC
RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
RFC 9001 - Using TLS to Secure QUIC
RFC 9002 - QUIC Loss Detection and Congestion Control
HTTP/3
QPACK
Load Balancers
Applicability
Manageability
Datagram
Version Negotiation
Greasing the QUIC bit
Acknowledgement Frequency
Main logging Schema
QUIC event definitions
HTTP/3 and QPACK event definitions
Т.е. существуют документы и по самому протоколу, по вспомогательным элементам протокола таким как QPACK, использование TLS вместо QUIC Crypto, балансировщикам. Есть документы для операторов Applicability & Manageability. Есть документы по расширениям, например тот же qlog, используемый для отладки. Нужна визуализация, не проблема - qvis.
Да QUIC получается более закрытым протоколом по отношению к посредникам, если вы не являетесь условно доверенным лицом одной из стороны обмена данными (а значит у вас вероятно нет доступа ни к qlog ни к другой внутренней и зашифрованной кухне протокола). Но это и к лучшему, а для посредников, обеспечивающих работоспособность соединений и т.д., а не внедрение и прослушивание потока - вся работа остаётся только в рамках IP/UDP.
Я для себя нашёл более спартанское решение линк.
Приземляю по крону раз в час файлик на роутер, а локальный резолвер этот файлик считывает и отдаёт клиентам, и все ноды в сети видят сиииильно меньше рекламы, а заодно меньше шансов что дочь на порнуху напорется или что жена по ссылке невесть какой пройдёт. и не надо ставить на 4 браузера помноженные на 5 устройств (и рут на андроиде ненужен)
Ага. Поддерживаю. Потому как я сам именно такой.
У меня школа, ВУЗ, еще один, куча вроде бы практики в бизнесе и разных проектах.
Все это круто, стильно, современно было в России.
Но все это в иной реальности, за границами России, стало полной фигней, шлаком и отстоем.
Инженерное и даже научное образование в России, сами его основы, настолько устарели и настолько отличаются от современных подходов, что даже оторопь берет.
В Польше тоже не лучше, а то и хуже бывает. Так что скорее всего это проблемы именно «возраста знаний» и впитанной в разум методологии, а не страны или социального уклада.
Что же касается стандартов в образовании, в разработке, в производстве — то тут все фигово.
Российские стандарты — чаще всего криво переведенные старые ISO стандарты.
Про «best practice» — еще все намного хуже.
Все это порождает огромную разницу в подходах к работе, совсем разную методологию работ. Ну и результат получается совсем иным.
Переделать себя, свой разум можно. Но приходится начинать с самых азов: от логики Аристотеля к системному подходу, от редукционизма — к холизму, от одномерной классификации — к многмерной, от метафоры работы «на листке бумаги» — к трехмерному проектированию, от восходящих (нисходящих) моделей проектирования — к циклическим, от придумывания новых компонентов — к оптимальному использованию готовых, от изобретательства — к инженерии (и потом обратно), от единственно верного «научного позитивизма» — к множеству научных методов по Лакатосу и Фейерабенду.
И 80% своего времени приходится тратить на постоянное само обучение. Учителя из институтов и школ тут бесполезны и часто вредны. Хотя не менее вредны и маститые практики, которые типа всегда на передовой реальной работы. Институты дают устаревшее и далекое от практики знание, но и практики учат только тому, что помнят или что им нравится, к чему они привыкли на работе.
Тут ведь как: нужно и проверенное на практике знание, и новое, новые методологии, чтобы развивать свои возможности. «Композитная структура знания»: слои твердого, практического знания и слои эластичного, нового знания. Причем одновременно. Тогда будет и эффективность (делаем то, что нужно и вовремя) и эластичность, изменчивость (делаем правильными методами, соответствующим ситуации).
Как-то так.
С двусвязными, конечно, но:
После прочтения ряда статей:
я думал, что я понял. После прочтения этой статьи я уже нихера не понимаю.
Я, как очень плохо учивший математику, понял категорию как некое обобщение над множествами, а сами множества являются одной из категорий (Set). А тип, вроде как, как раз укладывается в теорию множеств, как множество всех его допустимых значений. Так тип категория или нет?
Честно говоря, объяснение в порядке "функтор — аппликативный функтор — монада" понятнее, хотя, возможно, я его понял неправильно.
Функтор — отображение морфизма из одной категории в другую. Кстати, о
map. После некоторых размышлений мне стало казаться, что название функции означает не то, что она применяет некую функцию к контейнеру (как мы привыкли во всех языках, где естьmap), а именно отображение функции в другую категорию. Например, отображает морфизм "+" в категории чисел, в категорию "Maybe чисел". Мне это (либо очень очевидное, либо очень неправильное) понимание пришло в голову, если рассмотреть сигнатуру не как привычную функцию с двумя аргументамиmap(f, container) -> container, а как каррированную:Я прав?
Аппликативный функтор. А вот тут непонятно. Не, смотришь на картинки, на код, это, вроде, тоже самое, но для двух аргументов в контейнерах. Но что-то непонятно. Ладно, вот еще картинки с описанием. Это когда функции в контейнерах и аргументы в контейнерах. Понятнее не стало, да еще и не совпадает.
Монада. Такая штука, которая, в отличие от функтора, умеет работать не только с функциями
a -> b, но иa -> m b:Вроде бы, понятно, зачем оно нужно. И понятно, какую проблему (по сравнению с функтором) решает эта сигнатура, на примере тех же
Maybeочень понятно. Вот мы имеем цепочку каких-то функций, каждая возвращаетMaybe, их друг с другом биндим, все очень круто. А вот почему монада — контейнер? То, что условныйMaybe/Option/Nullableитп контейнеры — понятно. Зачем bind при работе с контейнерами — понятно. Но что-то интуитивного понимания нет. И еще почему "монада позволяет описать последовательность" (или что-то в этом роде)?З.Ы. Монада — тайпкласс. "Что-то" реализующее некие определенные методы является монадой. И "что-то" имеет какие-то данные, реализуем "интерфейс" (в курсе, что это очень грубая аналогия) монады (имея знание о структуре данных), чтобы функции, работающие с монадами, могла работать с нашим типом. Окей. Но с таким же успехом и функтор — контейнер, нет?
-name Win10 -machine pc,accel=kvm,dump-guest-core=off \
-vga none \
-no-fd-bootchk -serial none -parallel none -no-user-config -nodefaults -msg timestamp=off \
-boot once=c,menu=off \
-net nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:3389-10.0.2.5:3389 \
-device virtio-balloon \
-drive file=«Win10.qcow2»,if=virtio,format=qcow2,aio=native,cache.direct=on,index=0 \
-drive file=«swp.qcow2»,if=virtio,format=qcow2,aio=native,cache.direct=on,index=1 \
-vnc none