Это является следствием исправления бага в компиляторе.
К сожалению или к счастью, гарантии стабильности не распространяются на баги, иначе фиксить эти самые баги стало бы невозможно. Но если какой-то код случайно или намеренно полагался на баг, то может случиться ой подобный этому
Ситуация нестандартная, разработчики Rust регулярно тестируют все опубликованные крейты, чтобы убедиться в отсутствии регрессий
Event Loop'у нужны потоки, ибо в них он и работает.
Зависит от реализации. Стандартные event loop'ы в тех же Python и Node.js принципиально однопоточные и раскидывать задачи по потокам не умеют от слова совсем. Tokio runtime в Rust предоставляет Current-Thread Scheduler, который, как понятно из названия, работает в одном потоке и позволяет программисту не заботиться о возможном перекидывании задач между потоками.
Конечно, при всём при этом никто не запрещает закидывать cpu-bound и другие синхронные задачи в какой-нибудь пул потоков, но «это другое»™
В начале ветки поставлена задача «Сделать запрос к БД, отдать JSON», в которой из нагрузки на процессор разве что (де)сериализация. Какой смысл параллелить и балансировать околонулевую нагрузку? Есть подозрение, что на накладные расходы может потеряться больше)
В синхронных веб-приложениях «менеджер процессов/потоков» решает проблему вида «ой, воркеры кончились и принимать запрос некому», в то время как в асинхронных такой проблемы изначально нет, потому что event loop способен принять и обработать условно бесконечное количество запросов. Потоки и тем более процессы ему просто не требуются, пока не объявится какая-нибудь серьёзная cpu-bound задача или лютый highload
Очень жаль, если бы вы прочитали свою статью, то узнали бы про event loop, который делает «менеджер процессов/потоков» ненужным в большинстве задач)
Придумывать свой собственный event loop, разумеется, не нужно, уже есть сотни готовых реализаций, написанных людьми с квалификацией уровня примерно того же Сысоева, просто берём и пользуемся
Ну а «сервер приложений» настолько не нужен, что даже не упоминается там)
В node, go, асинхронном python, асинхронном rust и прочих асинхронных аналогах «сервер приложений, менеджер процессов/потоков» в принципе не нужны — одно лишь это уже является жирным преимуществом перед тем же FPM
(Впрочем, менеджер процессов/потоков иногда имеется, но он опционален)
А он работает? Лично у меня сайты с Cloudflare ECH не открываются ни в Firefox, ни в Chrome, из-за чего весь этот пост и комментаторы меня немного удивляют
Этот XSS ещё нужно умудриться найти, если он вообще есть. Непонятно, почему вы решили, что это просто
что часто
Почему вы решили что часто? Ну, например, вот вам челлендж — найдите любой XSS на любом из моих работающих сайтов, если «часто», то для вас это труда не составит, да? 🙃
Украсть RT - взломать пользовательский комп или сервер вебсайта или провайдера
У вас сильно нереалистичные представления о безопасности. Достаточно подсунуть юзеру вредоносное расширение «восстанавливающее ютуб» — юзер сам радостно тыкнет в «Дать доступ ко всем сайтам», это НАМНОГО проще чем XSS
Это является следствием исправления бага в компиляторе.
К сожалению или к счастью, гарантии стабильности не распространяются на баги, иначе фиксить эти самые баги стало бы невозможно. Но если какой-то код случайно или намеренно полагался на баг, то может случиться ой подобный этому
Ситуация нестандартная, разработчики Rust регулярно тестируют все опубликованные крейты, чтобы убедиться в отсутствии регрессий
Уж полвека как есть, /usr/lib называется
Только проблема как раз в том, что разные программы на самом деле хотят РАЗНЫЕ библиотеки
Да даже если луддизм - сайты реально падают под нагрузкой, даже мой личный сайт зачем-то регулярно дудосит Alibaba
Нет, речь именно об этом: если бизнес-логика зависнет и перестанет слать watchdog-сигналы, systemd всё прибьёт
Чушь, такое возможно только при кривой настройке
Если что, systemd такое умеет (WatchdogSec)
Aspia умеет работать с RDP-сессиями, только для этого нужно использовать Aspia Router (каждая сессия получает свой отдельный ID)
Зависит от реализации. Стандартные event loop'ы в тех же Python и Node.js принципиально однопоточные и раскидывать задачи по потокам не умеют от слова совсем. Tokio runtime в Rust предоставляет Current-Thread Scheduler, который, как понятно из названия, работает в одном потоке и позволяет программисту не заботиться о возможном перекидывании задач между потоками.
Конечно, при всём при этом никто не запрещает закидывать cpu-bound и другие синхронные задачи в какой-нибудь пул потоков, но «это другое»™
Не может, потому что WebKit основан на KHTML, который LGPL
(К хромовому Blink это тоже относится)
Не совсем без рукоприкладства, но спрашивает «Должен ли Bitwarden запомнить этот пароль?» и позволяет сохранить одним кликом
В начале ветки поставлена задача «Сделать запрос к БД, отдать JSON», в которой из нагрузки на процессор разве что (де)сериализация. Какой смысл параллелить и балансировать околонулевую нагрузку? Есть подозрение, что на накладные расходы может потеряться больше)
В синхронных веб-приложениях «менеджер процессов/потоков» решает проблему вида «ой, воркеры кончились и принимать запрос некому», в то время как в асинхронных такой проблемы изначально нет, потому что event loop способен принять и обработать условно бесконечное количество запросов. Потоки и тем более процессы ему просто не требуются, пока не объявится какая-нибудь серьёзная cpu-bound задача или лютый highload
Очень жаль, если бы вы прочитали свою статью, то узнали бы про event loop, который делает «менеджер процессов/потоков» ненужным в большинстве задач)
Придумывать свой собственный event loop, разумеется, не нужно, уже есть сотни готовых реализаций, написанных людьми с квалификацией уровня примерно того же Сысоева, просто берём и пользуемся
Ну а «сервер приложений» настолько не нужен, что даже не упоминается там)
Не приходится, потому что они не нужны. Вы не знаете, как работает асинхронщина?
В node, go, асинхронном python, асинхронном rust и прочих асинхронных аналогах «сервер приложений, менеджер процессов/потоков» в принципе не нужны — одно лишь это уже является жирным преимуществом перед тем же FPM
(Впрочем, менеджер процессов/потоков иногда имеется, но он опционален)
А он работает? Лично у меня сайты с Cloudflare ECH не открываются ни в Firefox, ни в Chrome, из-за чего весь этот пост и комментаторы меня немного удивляют
Этот XSS ещё нужно умудриться найти, если он вообще есть. Непонятно, почему вы решили, что это просто
Почему вы решили что часто? Ну, например, вот вам челлендж — найдите любой XSS на любом из моих работающих сайтов, если «часто», то для вас это труда не составит, да? 🙃
У вас сильно нереалистичные представления о безопасности. Достаточно подсунуть юзеру вредоносное расширение «восстанавливающее ютуб» — юзер сам радостно тыкнет в «Дать доступ ко всем сайтам», это НАМНОГО проще чем XSS
Почему вы так решили? httpOnly никак не помешает стянуть файлик с куками напрямую с устройства, например
Каким образом?
И все пользователи мобилок вас возненавидят
И очень зря
Даже wildcard?
Вот я из-за того и спросил, что там прямым текстом написано про отсутствие nginx и wildcard, а значит этот способ фактически бесполезен на практике
А в какой документации об этом почитать?