Поскольку у меня глаз очень чувствителен к спектру, то находиться в помещении со светодиодными лампами мне некомфортно, поэтому всю дорогу покупал галогенки. В моей люстре и с моим режимом эксплуатации их приходилось менять раз в 2 месяца. Попробовал эти — свет ничуть не хуже галогена, но нет присущего ему мерцания. Прошел уже почти год с момента покупки — ни одна не перегорела. Из других приятных приемуществ, это вместо 5 галогенок по 40w, сейчас горят 5 по 9w и при этом света больше.
Так что вы ошибаетесь: догнали, а служат уже гораздо дольше.
Светодиод светодиоду — рознь. То, о чем вы пишите, характерно для синих светодиодов. В данных лампах стоят фиолетовые, что и позволяет достигать CRI 98.
Замечу, что с момента выхода той статьи прошло много времени и выпущено много новых версий Unit-а, где мы провели ещё ряд существенных оптимизаций, которые суммарно должны были дать до +30% к производительности и снижению задержек. Да и множество новых возможностей появилось.
По идее да, должно быть легко, если они соответствуют спеке ASGI. Указал техническому писателю на эти фреймворки, он попробует и добавит по ним инструкции на сайт.
Вообще-то во всём мире на сегодняшний день не было обнаружено ни одного клинически подтвержденного случая повторного заражения, а существующие мутации вируса незначительны и не затрагивают ключевые белки, на которые реагирует имунная система.
С вашими знакомыми скорее всего одно из четырех:
1. Первый раз диагноз был ошибочный;
2. Второй раз диагноз был ошибочный;
3. Оба раза диагноз был ошибочный;
4. Не вылечились окончательно, а это всё одна большая вялотекущая болезнь, которая накатывает волнами (такое волновое течение ковиза отмечается многими).
На данный момент поддерживается только классический WSGI.
Мы последние несколько месяцев занимались серьезной переделкой внутреннего механизма распределения запросов по процессам приложения, фактически поменяв концепцию с push на pull в этом месте. Предыдущее решение оказалось неудачным — из-за чего в Go и Node.js наблюдаются проблемы с производительностью. Эта переделка войдет в ближайшую новую версию, которая выйдет уже в этом месяце. Данное изменение как раз позволит в дальнейшем хорошо поддержать асинхронные интерфейсы, а также ввести возможность многопоточной работы. Думаю поддержка ASGI может появиться уже до конца года.
Никаких веских причин, кроме отсутствия интереса со стороны сообщества веб-разработчиков.
Если бы Lua WSAPI был популярен, то давно бы уже сделали поддержку, но я ни одного запроса на это не припомню, как и других стандартизованных интерфейсов для веб-приложений на Lua. Да и популярных приложений и фреймворков, использующих Lua WSAPI — как-то не встречал. Тот же Orbit заброшен уже много лет. RestServer — также заброшен.Sputnik — заброшен. А что есть, может я не в курсе?
Openresty не является WSAPI сервером и поэтому его популярность тут мало релевантна. Это история исключительно про расширение nginx. Тот API, который предлагает Openresty для программирования веб-приложений на Lua — он крайне нишевый и сильно завязан на внутренности nginx, а у Unit от nginx нет практически ничего в плане кода и интерфейсов.
Openresty популярен не благодаря большой популярности Lua среди веб-программистов, а скорее благодаря тому, что не было другой вменяемой альтернативы расширять функциональность nginx. На тот момент nginx мог предложить только примитивный Perl-модуль, который к тому же не блистал производительностью и не рекомендовался в прод, либо модули на Си с крайне высоким входным порогом и большими трудозатратами на поддержку.
Unit — это история не про ещё один Node.js или Openresty (почему-то хочется поставить их рядом). Unit в плане поддержки языков программирования — это на данный момент история про запуск уже готовых популярных веб-приложений, существовавших задолго до Unit-а и использующих стандартизованные интерфейсы, общие для многих серверов: Python/WSGI, Perl/PSGI, PHP/SAPI, Ruby/Rack. На этом поле мы конкурируем с uWSGI, Gunicorn, Phusion Passenger, Unicorn, PHP-FPM и подобными.
Никакого большого замысла в этом нет. Проект соверешнно новый, написан практически с нуля. Посидели, подумали под какой лицензией его выкладывать: привычной нам «2-clause BSD-like» или что-то другое. Проконсультировались с юристами, посчитали, что Apache-2.0 будет не хуже и при этом теоретически лучше защитит пользователей, в том числе потому, что оговаривает отказ от патентных претензий.
и отношению к этому продукту нового собственника nginx
К тому, что об этом в своё время уже писал Игорь, мне особо добавить нечего: mailman.nginx.org/pipermail/nginx-ru/2019-March/061949.html — так оно есть и остается. С другой стороны в рамках крупной корпорации появилось больше возможностей для развития проекта, само собой больше ресурсов.
> Ну и для nginx это вполне себе фидбэк что пора бы завести динамические конфигурации и прочее чего Дропбоксу не хватило (возможно часть этого уже давно в проекте).
Это было понятно много лет назад, поэтому в том числе появился Unit. Наращиваем функциональность постепенно.
1. Безопасность. Другой процесс может незаметно начать слушать на этом же порту и получать часть соединений.
2. Потеря соединений при изменении числа рабочих процессов.
Вы смешали действие директив proxy_ignore_headers и proxy_hide_header. Директива proxy_ignore_headers не уберет заголовок из ответа клиенту, а лишь предотвратит его влияние на кэшируемость ответа.
Если вы хотити чтобы заголовок не передавался клиенту, то необходимо использовать директиву proxy_hide_header.
Так что вы ошибаетесь: догнали, а служат уже гораздо дольше.
А вот с aiohttp так не получится, поскольку его авторы похоже не понимают для чего нужны интерфейсы и поддержки ASGI там нет.
С вашими знакомыми скорее всего одно из четырех:
1. Первый раз диагноз был ошибочный;
2. Второй раз диагноз был ошибочный;
3. Оба раза диагноз был ошибочный;
4. Не вылечились окончательно, а это всё одна большая вялотекущая болезнь, которая накатывает волнами (такое волновое течение ковиза отмечается многими).
Мы последние несколько месяцев занимались серьезной переделкой внутреннего механизма распределения запросов по процессам приложения, фактически поменяв концепцию с push на pull в этом месте. Предыдущее решение оказалось неудачным — из-за чего в Go и Node.js наблюдаются проблемы с производительностью. Эта переделка войдет в ближайшую новую версию, которая выйдет уже в этом месяце. Данное изменение как раз позволит в дальнейшем хорошо поддержать асинхронные интерфейсы, а также ввести возможность многопоточной работы. Думаю поддержка ASGI может появиться уже до конца года.
Если бы Lua WSAPI был популярен, то давно бы уже сделали поддержку, но я ни одного запроса на это не припомню, как и других стандартизованных интерфейсов для веб-приложений на Lua. Да и популярных приложений и фреймворков, использующих Lua WSAPI — как-то не встречал. Тот же Orbit заброшен уже много лет. RestServer — также заброшен. Sputnik — заброшен. А что есть, может я не в курсе?
Openresty не является WSAPI сервером и поэтому его популярность тут мало релевантна. Это история исключительно про расширение nginx. Тот API, который предлагает Openresty для программирования веб-приложений на Lua — он крайне нишевый и сильно завязан на внутренности nginx, а у Unit от nginx нет практически ничего в плане кода и интерфейсов.
Openresty популярен не благодаря большой популярности Lua среди веб-программистов, а скорее благодаря тому, что не было другой вменяемой альтернативы расширять функциональность nginx. На тот момент nginx мог предложить только примитивный Perl-модуль, который к тому же не блистал производительностью и не рекомендовался в прод, либо модули на Си с крайне высоким входным порогом и большими трудозатратами на поддержку.
Unit — это история не про ещё один Node.js или Openresty (почему-то хочется поставить их рядом). Unit в плане поддержки языков программирования — это на данный момент история про запуск уже готовых популярных веб-приложений, существовавших задолго до Unit-а и использующих стандартизованные интерфейсы, общие для многих серверов: Python/WSGI, Perl/PSGI, PHP/SAPI, Ruby/Rack. На этом поле мы конкурируем с uWSGI, Gunicorn, Phusion Passenger, Unicorn, PHP-FPM и подобными.
К тому, что об этом в своё время уже писал Игорь, мне особо добавить нечего:
mailman.nginx.org/pipermail/nginx-ru/2019-March/061949.html — так оно есть и остается. С другой стороны в рамках крупной корпорации появилось больше возможностей для развития проекта, само собой больше ресурсов.
Это было понятно много лет назад, поэтому в том числе появился Unit. Наращиваем функциональность постепенно.
2. Потеря соединений при изменении числа рабочих процессов.
proxy_ignore_headersиproxy_hide_header. Директиваproxy_ignore_headersне уберет заголовок из ответа клиенту, а лишь предотвратит его влияние на кэшируемость ответа.Если вы хотити чтобы заголовок не передавался клиенту, то необходимо использовать директиву
proxy_hide_header.