@seaborgium1234 @bagder some protocols like #IPFS & #BitTorrent (#MagnetLink) are self-verifying by utilizing #hashes.
- Same with @torproject / #Tir's self-authenticating #NameSpace for
.oniondomains.
@seaborgium1234 @bagder some protocols like #IPFS & #BitTorrent (#MagnetLink) are self-verifying by utilizing #hashes.
.onion domains.#namespace ext_image_copy_capture ext_ext_image_copy_capture_
#namespace ext_image_copy_capture::manager_v1 manager_v1_
#namespace ext_image_capture_source ext_ext_image_capture_source_v1
#using ext_image_copy_capture as capture
#using ext_image_capture_source as image::source
#using capture::manager_v1 as image::manager
#using capture::session_v1 as image::session
#using capture::session_v1 as image::session
#using capture::manager_v1::create_session
extern struct image::manager *manager;
extern struct image::source *source;
struct image::session *session = create_session(manager, source);
or something similar
RE: https://social.vlhl.dev/objects/e95463e7-b873-413d-8669-0ec0cd50e084
thinking of the namespace proposal for c, and, i wonder if, we couldn’t have namespaces done in the preprocessor, like:
/* lib.h */
#namespace lib lib_
void lib::foo(); /* declares lib_foo as a function name */
/* app.c */
#include <lib.h>
#using lib::foo
#using lib::foo as nya
#using lib as MyApi
int main(void) {
/* all of those would be pre-processed to lib_foo() */
lib::foo();
foo();
nya();
MyApi::foo();
}
works with macros, and identifiers, basically anywhere a #define would also work
and could be backwards compatible, e.g. if i were to use it in openrc:
/* rc.h */
#ifdef _HAS_NAMESPACE
#namespace rc rc_
#namespace RC RC_
#endif
now older c programs can still use rc_service_resolve, and newer ones can use rc::service_resolve (as well as #using directives)
including whole namespace, like #using lib, could work but it’d be a pain to implement i think, since the preprocessor would need to keep track of all lib_ it sees since #namespace was declared, and forward-replace them
but with or without whole-namespace-inclusion, this has really simple semantics and imo predictable errors, as namespacing conflicts can be reported the same way “redefinition” of macro names are
[Перевод] Как мы освободили 7 ТиБ памяти
Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов , больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает. Но есть одна размерность, по которой, как мы подозреваем, мы почти на вершине: это пространства имён. Я думаю так, потому что мы постоянно сталкиваемся со странным поведением во всех процессах, которые их отслеживают. В частности, все процессы, выполняющие их listwatch, занимают на удивление много памяти и подвергают apiserver серьёзной нагрузке. Это стало одной из сложностей масштабирования, которую замечаешь, только достигая определённого порога. При увеличении оверхеда памяти эффективность снижается: каждый байт, который нам нужно использовать для управления — это байт, отнятый у пользовательских сервисов. Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов. Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.
https://habr.com/ru/articles/962642/
#пространство_имен #контейнеры #контейнеры_docker #поды #namespace
Maybe someone can use this and enhance it. #Joomla! #namespace
https://github.com/angieradtke/joomla_namespaces/blob/main/update_joomla_namespaces.php
When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.
> Namespaces are one honking great idea -- let's do more of those!
`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.
Don't do it.