docker-compose в репах дистрибутива может быть староват, а апстримовские релизы представляют собой самодостаточные бинари, сделанные pyinstaller, которые уже архитектурозависимы.
Заголовок: «игнорирует многопоточность микропроцессора AMD»
На самом деле: «использует 16 логических ядер из 32» (при том что для игр, логику в которых частенько трудно распараллелить, 16 это довольно-то дофига)
> Если думать о запуске разных копий программы, то тогда и про динамическую линковку надо думать.
Необязательно. Конечно, запуски разных программ не смогут разделять общие библиотеки, но запуски одной и той же программы разделять память с кодом вполне сможет.
Ничего про лицензирование не было в исходной новости. Исходная новость была чисто про модель разработки: насколько публичным будет багтрекер, обсуждения дизайна, возможность прислать патчи, и прочее.
Однако наш старый и добрый партнер, компания Cisco, сделала такое предложение, от которого не смог бы отказаться сам дон Корлеоне :), стоить отметить, что решающим фактором для принятия решения было конечно не цена.
Не, что в библиотеках есть wchar_t-совместимые интерфейсы — это хорошо. Но используются ли они в конечных программах?
Да и я вот посмотрел немного gettext, и там wchar_t как будто для Windows. Я не нашел ни одного вхождения wchar_t в хедерах, которые установлены gettext в моем линуксе.
В libxml2 тоже не нашел wchar_t в публичном интерфейсе.
ncurses действительно поддерживает параллельно char и wchar_t интерфейсы, это правда. Посмтрел несколько программ, которые зависят от ncurses — ncdu, htop — они используют char
> Если мы говорим об Unicode, то наметилась тенденция использования libunistring для его поддержки.
* CPython — wchar_t иногда используется для внутреннего представления юникодных строк. www.python.org/dev/peps/pep-0393
* Go — строки содержает произвольные байты, чаще всего UTF-8, изредка бинарные данные. blog.golang.org/strings. Выделенного юникодного типа нет.
* Rust — строки UTF-8. doc.rust-lang.org/std/primitive.str.html
* Linux (ядро) — все системные вызовы, принимающие строки, принимают нуль-терминированные строки char*, обычно семибитный ASCII или UTF-8 (хотя ядро никогда не знает, что это UTF-8, и никак с юникодом не работает (или очень редко)).
* libcurl — char* во всех интерфейсах.
Wireguard это всегда L3, поэтому добавить его в бридж не получится. Можно попробовать поверх Wireguard поднять какой-нибудь gretap/eiop, и уже его засунуть в бридж. Как обычно, в таких схемах нужно следить за MTU, иначе потом дебажить это будет совсем не весело.
Ну можно, только в обычный DNS можно подглядывать, и резать подозрительное, а что внутри DNS-over-HTTPS, корпоративному файерволлу/DNS-серверу не видно.
> Nginx при команде reload сбрасывает все активные подключения и это не лечится.
Смотря что подразумевается под активными. Открытые коннекты, в которых не выполняется никакой запрос, он действительно сбрасывает. Однако если какой-то запрос выполняется, то нет.
Я специально потестил: попробовал медленно качать большой файл, и сделать в этот момент reload. Скачка не прервалась, и воркер, на котором остался этот коннект, висит в списке процессов под именем «nginx: worker process is shutting down». Как только скачивание заканчивается, он выходит.
Наверное, то же, что и вам? Я не вижу ничего необычного вроде жалоб, что не работает.
Итак в чем преимущество ftp над скажем smb?… Над sftp
Ну я нигде и не говорил, что FTP фатально убог, и что его нужно закопать. Я полностью согласен, что FTP — это до сих пор lowest common denominator, который из коробки неплохо работает везде, в отличие от альтернатив. Всё, что я говорил — это то, что в протоколе есть несколько неудачные по сегодняшним меркам решения, связанные с использованием отдельного коннекта для данных.
Перевод: «самый обфусцированный backdoor»
wut
На самом деле: «использует 16 логических ядер из 32» (при том что для игр, логику в которых частенько трудно распараллелить, 16 это довольно-то дофига)
Необязательно. Конечно, запуски разных программ не смогут разделять общие библиотеки, но запуски одной и той же программы разделять память с кодом вполне сможет.
Откаты?
wchar_t-совместимые интерфейсы — это хорошо. Но используются ли они в конечных программах?Да и я вот посмотрел немного gettext, и там
wchar_tкак будто для Windows. Я не нашел ни одного вхожденияwchar_tв хедерах, которые установлены gettext в моем линуксе.В libxml2 тоже не нашел
wchar_tв публичном интерфейсе.ncurses действительно поддерживает параллельно
charиwchar_tинтерфейсы, это правда. Посмтрел несколько программ, которые зависят от ncurses — ncdu, htop — они используютchar> Если мы говорим об Unicode, то наметилась тенденция использования libunistring для его поддержки.
В документации libunistring есть такой занятный раздел: www.gnu.org/software/libunistring/manual/libunistring.html#The-wchar_005ft-mess
Я тоже накидаю примеров:
* CPython —
wchar_tиногда используется для внутреннего представления юникодных строк. www.python.org/dev/peps/pep-0393* Go — строки содержает произвольные байты, чаще всего UTF-8, изредка бинарные данные. blog.golang.org/strings. Выделенного юникодного типа нет.
* Rust — строки UTF-8. doc.rust-lang.org/std/primitive.str.html
* Linux (ядро) — все системные вызовы, принимающие строки, принимают нуль-терминированные строки
char*, обычно семибитный ASCII или UTF-8 (хотя ядро никогда не знает, что это UTF-8, и никак с юникодом не работает (или очень редко)).* libcurl —
char*во всех интерфейсах.wchar_tв мире Linux, и кучу примеров с UTF-8.Есть Qt с
QStringс UTF-16, но это вообще ни туда, ни сюда.wchar_tпрактически не используется. Везде UTF-8.Смотря что подразумевается под активными. Открытые коннекты, в которых не выполняется никакой запрос, он действительно сбрасывает. Однако если какой-то запрос выполняется, то нет.
Я специально потестил: попробовал медленно качать большой файл, и сделать в этот момент reload. Скачка не прервалась, и воркер, на котором остался этот коннект, висит в списке процессов под именем «nginx: worker process is shutting down». Как только скачивание заканчивается, он выходит.
perf traceНаверное, то же, что и вам? Я не вижу ничего необычного вроде жалоб, что не работает.
Ну я нигде и не говорил, что FTP фатально убог, и что его нужно закопать. Я полностью согласен, что FTP — это до сих пор lowest common denominator, который из коробки неплохо работает везде, в отличие от альтернатив. Всё, что я говорил — это то, что в протоколе есть несколько неудачные по сегодняшним меркам решения, связанные с использованием отдельного коннекта для данных.