у нас отдельные ingress ноды с traefik, и они натурально 4 проца, 8 гигов памяти, как патроны в магазине, маленькие и злые. одной ноды хватает на примерно 30к соединений при примерно 2к rps. при этом они скалируются горизонтально просто по нажатию кнопки. ну то есть потому что traefik нативен для k8s, достаточно просто добавлять ноды (при условии того что трафик приходит на них на все от провайдера) и они сразу начинают отдавать трафик. в прошлый ддос нам хватило 20 нод до того момент как умер входящий канал провайдера. как несложно посчитать это было примерно под полмиллиона соединений при 40к rps.
наверное можно упороться и поставить какие-нибудь страшно толстые сервера с 64 гигами памятипо 64 проца, вот только на них мгновенно возникнут сопутствующие проблемы - всякие настройки ядра, настройки сети, бесконечное переключение контекста, всё вот это вот связанное с сотнями тысяч открытых соединений к одной машине, к одному ядру. k8s, traefik и вот это вот всё оно именно как раз про утилитарность горизонтального масштабирования. когда можно в течение минуты поднять вместимость в небеса.
быстрее сдохнет бэкенд, чем ingress устанет.
и мы собираемся поменять ingress на envoy чтобы хватало 10 нод до того как умрёт входящий канал провайдера (это гипербола, мы очевидно начинаем применять другие меры когда перестаёт справляться чистый входящий канал провайдера). но уж точно не на nginx.
nginx кстати стоит за traefik и принимает соединения уже без tls из traefik, и я бы не сказал что он хорошо справляется... так себе, удовлетворительно.
и это всё, как вы видите, прямо конкретно мой, реальный опыт работы с этими приложениями. так что я бы поостерёгся рассказывать мне как хороши nginx'ы на широких просторах...
Там снизу грамотно заметили что можно поставить и наоборот - nginx спереди, Xray сзади. Active probe в этом случае не поможет, поможет только анализ TLS.
Но больше всего мне конечно хотелось бы спросить про DDoS это вы как бы сами испытывали, или просто "все знают" что nginx божественен, а golang это для консольных утилит какая-то приблуда?.. Потому что это вот прям как раз то, что именно вот прям со мной, случается время от времени. И даже тот же самый traefik который мы используем вполне себе выдерживает такую же нагрузку как nginx. А ещё он при этом нативно горизонтально скалируется в кластере, чуть более удобно чем nginx, который про соседей никогда ничего не знает, хоть это и не так важно в горизонтальном скалировании. Но даже это не предел, потому что вдруг внезапно оказывается что если сделать замеры, то nginx при включённом TLS (что как бы подразумевается в нынешнем интернете) это самое тормозное дно в плане RPS которое проигрывает и traefik (хоть и немного), и особенно envoy (уже много). Если не опираться на "я так вижу", а допустим почитать всякие замеры из интернета, то можно найти прямо вот такие вот печальные графики
и у всех трестировавши они будут одинаковые... эпоха nginx проходит, так же как когда-то проходила эпоха apache, и мы все находимся сейчас где-то в том районе где все вокруг все ещё считали nginx какой-то мутной поделкой, а апач стандартом индустрии, только дедушка теперь уже nginx.
Fingerprint Firefox... Ах, ну да... Наверное если мы говорим про хендшейк клиента. Xray как клиент конечно наверное где-то в районе 2021-го года выглядел как библиотека на go. И это конечно довольно просто решается на клиенте маскировкой под браузер. Согласен.
Я всё же имел ввиду серверную часть. В статье много внимания уделено тому как golang сервер отличается от nginx на уровне TLS хендшейка. И вот тут не могу не подчеркнуть, что, даже несмотря на то, что Xray и сейчас может выглядеть как сервер написаный на golang - блокировать именно такое на стороне сервера - самоубийство. После стремительного восхода Envoy, который сейчас уже очень широко распространён.
Для начала "написан на go, и вот так-то его легко поймать, отличив от нашего святого nginx" - это если вы застряли в 2020. nginx стремительно проигрывает битву за то, что называется "ingress controller". Это именно то, что роутит трафик на входе в кубер или в чем-то ещё более высоко нагруженом. Схема - на входе контроллер терминирующий tls, за ним уже всякие nginx c проложениями - уже практически стандарт в больших деплойментах, и уж особенно везде где есть кубер. И написаны они... Сюрприз-сюрприз, на golang! Envoy, Traefik,.. вот эта вся братия - уже солидная часть интернета отвечающего на TLS. Так что вот так вот взять и зарубить хендшейк golang - тот же верный способ выстрелить себе сразу в обе ноги, как заблокировать телеграм по айпишникам.
Нормально настроенный Xray не распознав в хендшейке своего клиента запросто передаёт соединение дальше даже не повреждая TLS. Можно поставить спереди Xray, сзади хоть mictrosoft.com и притворяться его CDN без всякой дефолтной страницы Nginx. А "распознаёт" в контексте Xray - это не "ошибочки пишет если что-то не так", - это жёстко чуть ошибся в конфиге клиента, и ничего не работает, потому что трафик уходит на microsoft.com. Там всё так сделано что или ты клиент, или получаешь страницу от fallback. Никаких "ошибочек" там нет.
Конечно это не прям панацея, я просто слегка поверхностно описал почему грамотно настроенный Xray это не то что можно найти с полпинка.
Но тут мы приближаемся к пучинам DPI и вычислительных затрат, которые придётся потратить на каждое соединение чтобы сказать "да вроде это Xray... похоже... может быть". Затраты на прям вот такой DPI будут жечь невероятное количество CPU. К тому же хвалёному китайскому фаерволу пришлось блокировать QUIC полностью, потому что он просто ложился расшифровывая его SNI на не совсем даже катастрофическом количестве трафика.
Так что в целом Xray still going strong.
А уж учитывая сколько там в него добавляют и добавляют, - вполне можно надеяться что всегда будет механизм на шаг впереди DPI.
IPSec не часть IPv6. если в статье написано про "встроенную поддержку IPSec" - это сразу маркёр перепечатки которую тянут друг за другом все кто ни разу в жизни не работал с IPv6 и просто пишет по мотивам того что прочитал
"ундицилионны" или как их там адресов, - это преувеличение, которое легко сделать если напрямую проецировать опыт работы с ipv4 на ipv6. то что в ipv4 один айпишник, в ipv6 представляет из себя /64 подсеть. любой механизм выделения адресов конечным устройствам подразумевает что вы владеете минимум подсетью /64. провайдеры выдают конечным пользователям сразу по /64 сети, иначе это не работает. а чаще всего и по /56 и по /48. так что реальный объём прям вот адресов которые можно раздать "клиентам" (а не конечным устройствам) ну прямо сильно меньше. меньше /64 сети раздавать в руки даже самого распоследнего василия на модеме 14400 в деревне не получится.
Вы так говорите, как будто закрывать квартиру (и национальный русский дериватив от этого - стальная дверь в квартиру, и в подъезд, дающая этот ни с чем не сравнимый вид и ощущение входа в тюремный блок), и ставить машину на сигнализацию это позитивные качества к которым надо стремиться...
По моему жить в месте, и среди людей, с которыми не надо закрывать ни квартиру ни машину, и самому так себя вести - это как раз нормально.
Вы проецируете собственный опыт (как ФСБ может прийти в любую компанию и та бахнется в коленно-локтевую позу перед ними) на весь мир. Это не так. АНБ "запросит" у гугла трафик Саши из Москвы, и приложит к этому все юридические обоснования этого - открытое дело, обвинения предъявленные, и обоснование что именно вот этот вот трафик является уликой по этому делу рассматриваемому в суде. И если гугловским юристам что-то не понравится АНБ пойдёт домой к себе, маме жаловаться со всеми своими плохо заполненными бумажками.
Так уже было не раз с тем же Эпплом, который просто отказался вскрывать телефоны людей, которые уже сидели в тюрьме, уже были обвинены в терроризме или наркотрафике, но даже при этом всё равно юридических оснований пришить именно эти телефоны у них изъятые именно к этому делу не было.
Именно в этом и заключается идея разделения власти - когда нет той самой "вертикали", где всегда найдётся верхний способный пнуть нижнего не смотря на любые законы.
PS. Пожалуйста не надо вываливать в качестве ответа все эти конспирологические теории "ах вы такой наивный, вы ничего не понимаете, просто придут и никого не спросят и никто не узнает! всё везде одинаково, везде как в России, только на пёсьих языках говорят"
microled это не про разрешение, а про качество изображения.
у LED проблема в том что светит вся подложка как фонарь, а кристаллы перекрывают этот свет по всякому и получаются светлые и тёмные части. где-то где кристаллы закрылись сильнее - тёмное, где-то где открылись - светлое. технология не идеальная, потому что кристаллы перекрывают свет не на сто процентов. из-за этого чёрные места на изображении не чёрные, а шакально-серого цвета (подложка-то всё равно светит во всю за ними). можно сколько угодно возмущаться "да я ваще такого не вижу!", но это просто иллюзия нашего мозга, - если все телевизоры вокруг показывают чёрный серым, мы считаем это нормальным и "не видим". но стоит только посмотреть в гостях blueray на OLED... тут-то иллюзия и разваливается...
OLED это технология без фонаря в основе, где каждый конкретный пиксель - сам по себе источник света, что даёт идеальные цвета, но имеет свои недостатки - он тёмный, потому что очевидно если пиксели жарить так, чтобы они светили так, как может огромный фонарь, - они быстро деградируют. OLED хорошо смотреть в тёмных комнатах, вот там это всё очень потрясающе выглядит. если комната светлая - будет средненько за большие деньги.
Есть промежуточная технология MiniLED, где сзади не один сплошной фонарь, а секции, и в зависимости от того где изображение чёрное а где нет - секции включаются и выключаются. Как понимаете выглядит это всё не идеально, если телевизор дешёвый то вообще максимально шакально, когда например на видео космоса вылетает луна и включается целая вертикальная полоса снизу доверху чтобы подсветить одну луну. Но в целом сейчас производители достигли неплохого качества в этом плане. чем больше секций тем лучше, но надо понимать что секций на телевзоре не тысячи, а десятки, в хороших моделях сотни (что тоже буквально 10х15) и цена уже приближается к OLED.
И вот наш (поклонников хорошего изображения) который год святой грааль - MicroLED, - где каждый пиксель получает свою собственную подстветку. Что должно решить сразу все проблемы, - и шакальный чёрный, и не самую высокую возможную яркость. К сожалению уже который год это либо "скоро" либо очень-очень дорого и в целом больше смахивает на какие-то штучные прототипы.
Вот прям примерно тоже самое хотел написать. Человек взял совершенно незнакомую ему область и сравнил все препятствия которые он для себя в ней открыл со сложностями планирования в той области где он как бы должен быть профессионал?.. вопросики как бы тут возникают в причинах плохих оценок сроков разработки, к этому конкретному автору.
Я тоже было дело заезжал первый в новый дом, и примерно так же навеселился со стиралкой. Но сделав это один раз я даже статью не стал дочитывать, потому что получив такой опыт один раз вопросы которые надо уточнять и оценивать совершенно ясны - розетка, вода, слив, шланги, фиттинги, расстояния, место установки, удобство подъезда.
Согласен с тремя четвертями, всё верно - никакого "отовсюду убрали" не было, все кто так пишет - лгут. Убрали из мейнтейнеров, это список лиц которые могут подтверждать патчи других людей и они будут приняты в ядро. В человеческих терминах - просто исключили из совета директоров (если можно себе представить совет директоров человек на 500). И код и все имена всё всё всё везде осталось. И новый код они присылать вполне могут. У них просто забрали право подтвердить чужой код на включение в ядро.
Но вот то что это было некрасиво я не согласен. Убрали их вполне нормально, вычеркнул из списка мейнтейнеров тот, кто этот список ведёт, кто определяет кто в ядро может код вносить.
Ну и ответили на претензии вполне адекватно. Всё же линукс не коммерческая компания работающая для получения прибыли, ей перед инвесторами отчитываться не надо, и состоит она в основном не из людей боящихся потерять работу, а из довольно умных программистов которым ни политики не указ, ни всякие прогрессивные движения. Написали что думают. Как в интернете пишут. Такие дела...
ну он отправляется один раз и кэшируется на сколько скажешь в ответе... обычно API довольно ограниченное количество, OPTIONS ко всему что используется на странице пролетит мгновенно по мере надобности и будет запомнен для всех последующих запросов.
да, есть какие-то накладные расходы, но в вебе разница в 50 миллисекунд это... ну камон... у меня эта статья сейчас открывалась примерно полторы секунды пока всё догрузила...
Так делают... Это самое простое решение к которому склоняются все, когда встаёт выбор - разобраться с такой довольно сложной вещью как CORS, поставить Allow: *, сделать всё на том же хосте с прокси к сервисам. Чаще всего опыта чтобы отбросить уровень 0 (поставить Allow: *) уже хватает, а вот количество усилий нужное на качественный скачок до уровня 2 - сделать CORS по уму, по сравнению с уровнем 1 - сбацать всё на прокси кажется просто непропорциональным.
И я честно даже не буду играть в сноба от того что я разобрался с CORS, можно и на прокси. Действительно реальных технических плюсов выделяющий тот или иной подход - нет. Кроме того что прокси понятней и проще.
Тут кстати очень характерна недавняя история с Google Chrome который собрался депрекейтить cross-site cookie в ноль, так чтобы они вообще не работали в браузере. У них так и было написано в дисклеймере, если вам реально нужно передавать авторизацию на сторонние сайты - делайте прокси через тот сайт с которым вы работаете. То есть даже большие корпорации "делающие" наш интернет вполне адекватно оценивают сложности того или иного подхода. Но всё же дело закончилось тем, что они отменили своё решение, и cross-site cookie продолжат работу, потому что видимо всё же нашлись реальные большие кейсы когда такой подход - верный. И мне кажется чтобы переубедить гугл нужны веские аргументы что вот такой подход (в этом случае часть CORS, даже не весь, о похоронах CORS как жаждет автор статьи речь даже не шла) - необходимая технология.
Чё-то я ваще не согласен. Статья какого-то страшно разгневанного нерда у которого интернет не работает так как ему нравится.
"Соответственно, скрипт может выполнить POST https://your-bank.example/transfer?to=fungames&amount=1000000000 и переправить миллиард долларов на счёт своего хозяина." - нет не выполнит. любой браузер сначала отправит чистый OPTIONS вообще без всяких авторизаций, и если не получит в ответ CORS политику разрешающую и запрос и отправку куки - ни пса он не выполнит.
"Один из лучших способов в принципе избежать такой проблемы – это отказаться от использования неявных учётных данных." - нифига мне не нравится такой вариант. в таком варианте токен авторизации будет где-то болтаться посреди javascript, где-то его можно будет прочитать из payload и так далее. тогда как cookie можно поставить httponly, и она будет в принципе недоступна javascript. авторизация будет разделена от функциональности и выковыривать её если что надо будет из другого места, если уж удалось заинжектить клиенту вредоносный скрипт.
"Наилучшее решение — настроить на стороне сервера промежуточное ПО таким образом, чтобы оно игнорировало неявные учётные данные при всех межсайтовых запросов." - так можно было бы их вообще запретить в браузере и дело с концом! раз кому-то они так не нравятся. но дело-то в том что они как раз нужны в сложных системах. например есть веб морда какого-то сложного сервиса, который тянет API с нескольких микросервисов, не имеет своего состояния, и использует как раз запросы на микросервисы по другим URL. и вот тут-то всё это склеивается нормально настроеной CORS политикой. для чего она собственно и сделана и в контексте чего отлично работает и все её опции и методы работы понятны. независимо от того что некоторых операторов локалхоста эти все "ненужные" сложности бесят.
ну так принимающая микросхема должна же как-то понимать текущую частоту входящего потока? представьте что в канале тишина, а это постоянно происходит в звуке, при частоте семплов в 44100 в секунду, - огромная часть семплов будет просто пустая. как из стабильного нуля в канале понять с какой он частотой поступает?
определять из первых семплов которые отличаются от нуля? можно, на это нужно примерно несколько десятков семплов по спекам любого DAC. выглядеть это будет как отрезание доли миллисекунды на каждой смене тишина-звук. что в принципе может быть и незаметно, настолько быстро это происходит, но как минимум выглядит как знатный костыль, и конечно же вызовет широкий спектр инфарктов на форумах аудифилов, с вечным проклятием цифрового воспроизведения как неизлечимой ереси.
Нет, это исходит из того что I2S это звук который передаётся с какой-то дискретизацией, 44100, 48000,.. вот эти вот смешные цифры из эпохи mp3, - это частота звукового цифрового потока. и I2S как протокол не подразумевает что эта частота всегда одна и та же, или какого-то соглашения между источником и потребителем о том какой она будет на всё время работы.
Живой пример - вы проигрываете файл mp3 на компьютере mp3 44100, он поступает на DAC как I2S прямо со своей частотой 44100. А потом вы берёте и открываете другой файл, который имеет частоту 48000. Тут возможно было несколько подходов как это могло бы быть сделано:
I2S мог иметь что-то типа SPI входа по которому можно было бы "устанавливать" текущую частоту, которую он как вы выражаетесь "запоминал бы". Но это бы означало внедрение во все чипы I2S какой-то рудиментарной микроконтроллерной логики, довольно дорогое решение для дизайна IC. Причём нужно было бы поддерживать эту логику с двух сторон - источник управляемый проигрывателем ставил бы её, а получатель ожидал. Довольно сложная схема.
I2S мог бы работать на установленной на старте частоте, и тогда бы любой источник должен был бы перекодировать все проигрываемые файлы к этой частоте, что про конверсиях 48000 -> 44100 давало бы "артефакты", ну просто потому что это не 1:2 и даже не какой-нибудь 11:54, - там очень неочевидная дробь, и заодной вызывала бы сердечный приступ и аудиофилов на форумах одним упоминанием "цифровых артефактов перекодировки" (кстати спойлер, - современные устройства практически не дают артефактов. я использую это в хардварном I2S микшере с несколькими входами и мне не удалось услышать ничего что можно и близко назвать искажениями). и это ещё ладно на компьютере, а как бы страшно усложнялись хардварные проигрыватели, где микросхем общающихся по I2S обычно несколько.
I2S мог быть сделан так, что в него всегда поступает опорная частота, и он просто работает на этой частоте разбирая поступающий по другому пину поток с этой скоростью. Меняется частота - меняется скорость, меняются места где ожидаются начала битов. На выходе это всё равно превращается в гладкую аналоговую синусоиду, какая разница с какой частотой там исходная лесенка... По этому пути и пошёл дизайн. Просто, надёжно, дешево.
Да уж, какая-то не впечатляющая интрига вышла... Ведь в даташите любого DAC/ADC на I2S будет написано - либо подавайте опорную частоту на CLKIN, либо конфигурируйте чип на автоматическое выделение опорной частоты из BCK.
Вы так говорите, как будто "оппозиция" это всегда про "свергать правительства". Да и вообще как-то странно это звучит, чтобы вдруг кто-то просто переписывался друг с другом, а их за это надо было бы преследовать нарушая право на частную жизнь. Это ж как в диктаторских режимах чтоли?.. Вот это да!
Срочно пишите всем вокруг эти невероятные новости, надо же всем вокруг доказать что проект с открытым исходным кодом который понятно и доступно, для тех кто в этом разбирается, работает, сделан для того чтобы всех поймать и посадить используя скрытые технологии о которых никому не известно...
signal это же просто мессенджер? как его можно "использовать для смены режимов"? даже если отвлечься от желтушности самой терминологии, это же не платформа для публикаций, не средство для перевода денег, это же просто мессенджер???
суть примерна та же, что и "русский язык используется для смены режимов по всему миру". или "рубли, выпускаемые центрабанком, используются в совершения преступлений по всей России"
у нас отдельные ingress ноды с traefik, и они натурально 4 проца, 8 гигов памяти, как патроны в магазине, маленькие и злые. одной ноды хватает на примерно 30к соединений при примерно 2к rps. при этом они скалируются горизонтально просто по нажатию кнопки. ну то есть потому что traefik нативен для k8s, достаточно просто добавлять ноды (при условии того что трафик приходит на них на все от провайдера) и они сразу начинают отдавать трафик. в прошлый ддос нам хватило 20 нод до того момент как умер входящий канал провайдера. как несложно посчитать это было примерно под полмиллиона соединений при 40к rps.
наверное можно упороться и поставить какие-нибудь страшно толстые сервера с 64 гигами памятипо 64 проца, вот только на них мгновенно возникнут сопутствующие проблемы - всякие настройки ядра, настройки сети, бесконечное переключение контекста, всё вот это вот связанное с сотнями тысяч открытых соединений к одной машине, к одному ядру. k8s, traefik и вот это вот всё оно именно как раз про утилитарность горизонтального масштабирования. когда можно в течение минуты поднять вместимость в небеса.
быстрее сдохнет бэкенд, чем ingress устанет.
и мы собираемся поменять ingress на envoy чтобы хватало 10 нод до того как умрёт входящий канал провайдера (это гипербола, мы очевидно начинаем применять другие меры когда перестаёт справляться чистый входящий канал провайдера). но уж точно не на nginx.
nginx кстати стоит за traefik и принимает соединения уже без tls из traefik, и я бы не сказал что он хорошо справляется... так себе, удовлетворительно.
и это всё, как вы видите, прямо конкретно мой, реальный опыт работы с этими приложениями. так что я бы поостерёгся рассказывать мне как хороши nginx'ы на широких просторах...
"может быть nginx" https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
Там снизу грамотно заметили что можно поставить и наоборот - nginx спереди, Xray сзади. Active probe в этом случае не поможет, поможет только анализ TLS.
Но больше всего мне конечно хотелось бы спросить про DDoS это вы как бы сами испытывали, или просто "все знают" что nginx божественен, а golang это для консольных утилит какая-то приблуда?.. Потому что это вот прям как раз то, что именно вот прям со мной, случается время от времени. И даже тот же самый traefik который мы используем вполне себе выдерживает такую же нагрузку как nginx. А ещё он при этом нативно горизонтально скалируется в кластере, чуть более удобно чем nginx, который про соседей никогда ничего не знает, хоть это и не так важно в горизонтальном скалировании. Но даже это не предел, потому что вдруг внезапно оказывается что если сделать замеры, то nginx при включённом TLS (что как бы подразумевается в нынешнем интернете) это самое тормозное дно в плане RPS которое проигрывает и traefik (хоть и немного), и особенно envoy (уже много). Если не опираться на "я так вижу", а допустим почитать всякие замеры из интернета, то можно найти прямо вот такие вот печальные графики
и у всех трестировавши они будут одинаковые... эпоха nginx проходит, так же как когда-то проходила эпоха apache, и мы все находимся сейчас где-то в том районе где все вокруг все ещё считали nginx какой-то мутной поделкой, а апач стандартом индустрии, только дедушка теперь уже nginx.
Fingerprint Firefox... Ах, ну да... Наверное если мы говорим про хендшейк клиента. Xray как клиент конечно наверное где-то в районе 2021-го года выглядел как библиотека на go. И это конечно довольно просто решается на клиенте маскировкой под браузер. Согласен.
Я всё же имел ввиду серверную часть. В статье много внимания уделено тому как golang сервер отличается от nginx на уровне TLS хендшейка. И вот тут не могу не подчеркнуть, что, даже несмотря на то, что Xray и сейчас может выглядеть как сервер написаный на golang - блокировать именно такое на стороне сервера - самоубийство. После стремительного восхода Envoy, который сейчас уже очень широко распространён.
Для начала "написан на go, и вот так-то его легко поймать, отличив от нашего святого nginx" - это если вы застряли в 2020. nginx стремительно проигрывает битву за то, что называется "ingress controller". Это именно то, что роутит трафик на входе в кубер или в чем-то ещё более высоко нагруженом. Схема - на входе контроллер терминирующий tls, за ним уже всякие nginx c проложениями - уже практически стандарт в больших деплойментах, и уж особенно везде где есть кубер. И написаны они... Сюрприз-сюрприз, на golang! Envoy, Traefik,.. вот эта вся братия - уже солидная часть интернета отвечающего на TLS. Так что вот так вот взять и зарубить хендшейк golang - тот же верный способ выстрелить себе сразу в обе ноги, как заблокировать телеграм по айпишникам.
Нормально настроенный Xray не распознав в хендшейке своего клиента запросто передаёт соединение дальше даже не повреждая TLS. Можно поставить спереди Xray, сзади хоть mictrosoft.com и притворяться его CDN без всякой дефолтной страницы Nginx. А "распознаёт" в контексте Xray - это не "ошибочки пишет если что-то не так", - это жёстко чуть ошибся в конфиге клиента, и ничего не работает, потому что трафик уходит на microsoft.com. Там всё так сделано что или ты клиент, или получаешь страницу от fallback. Никаких "ошибочек" там нет.
Конечно это не прям панацея, я просто слегка поверхностно описал почему грамотно настроенный Xray это не то что можно найти с полпинка.
Но тут мы приближаемся к пучинам DPI и вычислительных затрат, которые придётся потратить на каждое соединение чтобы сказать "да вроде это Xray... похоже... может быть". Затраты на прям вот такой DPI будут жечь невероятное количество CPU. К тому же хвалёному китайскому фаерволу пришлось блокировать QUIC полностью, потому что он просто ложился расшифровывая его SNI на не совсем даже катастрофическом количестве трафика.
Так что в целом Xray still going strong.
А уж учитывая сколько там в него добавляют и добавляют, - вполне можно надеяться что всегда будет механизм на шаг впереди DPI.
Не устану писать под каждой статьёй про ipv6:
IPSec не часть IPv6. если в статье написано про "встроенную поддержку IPSec" - это сразу маркёр перепечатки которую тянут друг за другом все кто ни разу в жизни не работал с IPv6 и просто пишет по мотивам того что прочитал
"ундицилионны" или как их там адресов, - это преувеличение, которое легко сделать если напрямую проецировать опыт работы с ipv4 на ipv6. то что в ipv4 один айпишник, в ipv6 представляет из себя /64 подсеть. любой механизм выделения адресов конечным устройствам подразумевает что вы владеете минимум подсетью /64. провайдеры выдают конечным пользователям сразу по /64 сети, иначе это не работает. а чаще всего и по /56 и по /48. так что реальный объём прям вот адресов которые можно раздать "клиентам" (а не конечным устройствам) ну прямо сильно меньше. меньше /64 сети раздавать в руки даже самого распоследнего василия на модеме 14400 в деревне не получится.
Вы так говорите, как будто закрывать квартиру (и национальный русский дериватив от этого - стальная дверь в квартиру, и в подъезд, дающая этот ни с чем не сравнимый вид и ощущение входа в тюремный блок), и ставить машину на сигнализацию это позитивные качества к которым надо стремиться...
По моему жить в месте, и среди людей, с которыми не надо закрывать ни квартиру ни машину, и самому так себя вести - это как раз нормально.
О! Очередные 10 лучших способов замазать синяки от инъекций героином!..
Вы проецируете собственный опыт (как ФСБ может прийти в любую компанию и та бахнется в коленно-локтевую позу перед ними) на весь мир. Это не так. АНБ "запросит" у гугла трафик Саши из Москвы, и приложит к этому все юридические обоснования этого - открытое дело, обвинения предъявленные, и обоснование что именно вот этот вот трафик является уликой по этому делу рассматриваемому в суде. И если гугловским юристам что-то не понравится АНБ пойдёт домой к себе, маме жаловаться со всеми своими плохо заполненными бумажками.
Так уже было не раз с тем же Эпплом, который просто отказался вскрывать телефоны людей, которые уже сидели в тюрьме, уже были обвинены в терроризме или наркотрафике, но даже при этом всё равно юридических оснований пришить именно эти телефоны у них изъятые именно к этому делу не было.
Именно в этом и заключается идея разделения власти - когда нет той самой "вертикали", где всегда найдётся верхний способный пнуть нижнего не смотря на любые законы.
PS. Пожалуйста не надо вываливать в качестве ответа все эти конспирологические теории "ах вы такой наивный, вы ничего не понимаете, просто придут и никого не спросят и никто не узнает! всё везде одинаково, везде как в России, только на пёсьих языках говорят"
microled это не про разрешение, а про качество изображения.
у LED проблема в том что светит вся подложка как фонарь, а кристаллы перекрывают этот свет по всякому и получаются светлые и тёмные части. где-то где кристаллы закрылись сильнее - тёмное, где-то где открылись - светлое. технология не идеальная, потому что кристаллы перекрывают свет не на сто процентов. из-за этого чёрные места на изображении не чёрные, а шакально-серого цвета (подложка-то всё равно светит во всю за ними). можно сколько угодно возмущаться "да я ваще такого не вижу!", но это просто иллюзия нашего мозга, - если все телевизоры вокруг показывают чёрный серым, мы считаем это нормальным и "не видим". но стоит только посмотреть в гостях blueray на OLED... тут-то иллюзия и разваливается...
OLED это технология без фонаря в основе, где каждый конкретный пиксель - сам по себе источник света, что даёт идеальные цвета, но имеет свои недостатки - он тёмный, потому что очевидно если пиксели жарить так, чтобы они светили так, как может огромный фонарь, - они быстро деградируют. OLED хорошо смотреть в тёмных комнатах, вот там это всё очень потрясающе выглядит. если комната светлая - будет средненько за большие деньги.
Есть промежуточная технология MiniLED, где сзади не один сплошной фонарь, а секции, и в зависимости от того где изображение чёрное а где нет - секции включаются и выключаются. Как понимаете выглядит это всё не идеально, если телевизор дешёвый то вообще максимально шакально, когда например на видео космоса вылетает луна и включается целая вертикальная полоса снизу доверху чтобы подсветить одну луну. Но в целом сейчас производители достигли неплохого качества в этом плане. чем больше секций тем лучше, но надо понимать что секций на телевзоре не тысячи, а десятки, в хороших моделях сотни (что тоже буквально 10х15) и цена уже приближается к OLED.
И вот наш (поклонников хорошего изображения) который год святой грааль - MicroLED, - где каждый пиксель получает свою собственную подстветку. Что должно решить сразу все проблемы, - и шакальный чёрный, и не самую высокую возможную яркость. К сожалению уже который год это либо "скоро" либо очень-очень дорого и в целом больше смахивает на какие-то штучные прототипы.
Вот прям примерно тоже самое хотел написать. Человек взял совершенно незнакомую ему область и сравнил все препятствия которые он для себя в ней открыл со сложностями планирования в той области где он как бы должен быть профессионал?.. вопросики как бы тут возникают в причинах плохих оценок сроков разработки, к этому конкретному автору.
Я тоже было дело заезжал первый в новый дом, и примерно так же навеселился со стиралкой. Но сделав это один раз я даже статью не стал дочитывать, потому что получив такой опыт один раз вопросы которые надо уточнять и оценивать совершенно ясны - розетка, вода, слив, шланги, фиттинги, расстояния, место установки, удобство подъезда.
Согласен с тремя четвертями, всё верно - никакого "отовсюду убрали" не было, все кто так пишет - лгут. Убрали из мейнтейнеров, это список лиц которые могут подтверждать патчи других людей и они будут приняты в ядро. В человеческих терминах - просто исключили из совета директоров (если можно себе представить совет директоров человек на 500).
И код и все имена всё всё всё везде осталось. И новый код они присылать вполне могут. У них просто забрали право подтвердить чужой код на включение в ядро.
Но вот то что это было некрасиво я не согласен. Убрали их вполне нормально, вычеркнул из списка мейнтейнеров тот, кто этот список ведёт, кто определяет кто в ядро может код вносить.
Ну и ответили на претензии вполне адекватно. Всё же линукс не коммерческая компания работающая для получения прибыли, ей перед инвесторами отчитываться не надо, и состоит она в основном не из людей боящихся потерять работу, а из довольно умных программистов которым ни политики не указ, ни всякие прогрессивные движения. Написали что думают. Как в интернете пишут. Такие дела...
ну он отправляется один раз и кэшируется на сколько скажешь в ответе... обычно API довольно ограниченное количество, OPTIONS ко всему что используется на странице пролетит мгновенно по мере надобности и будет запомнен для всех последующих запросов.
да, есть какие-то накладные расходы, но в вебе разница в 50 миллисекунд это... ну камон... у меня эта статья сейчас открывалась примерно полторы секунды пока всё догрузила...
Так делают... Это самое простое решение к которому склоняются все, когда встаёт выбор - разобраться с такой довольно сложной вещью как CORS, поставить Allow: *, сделать всё на том же хосте с прокси к сервисам. Чаще всего опыта чтобы отбросить уровень 0 (поставить Allow: *) уже хватает, а вот количество усилий нужное на качественный скачок до уровня 2 - сделать CORS по уму, по сравнению с уровнем 1 - сбацать всё на прокси кажется просто непропорциональным.
И я честно даже не буду играть в сноба от того что я разобрался с CORS, можно и на прокси. Действительно реальных технических плюсов выделяющий тот или иной подход - нет. Кроме того что прокси понятней и проще.
Тут кстати очень характерна недавняя история с Google Chrome который собрался депрекейтить cross-site cookie в ноль, так чтобы они вообще не работали в браузере. У них так и было написано в дисклеймере, если вам реально нужно передавать авторизацию на сторонние сайты - делайте прокси через тот сайт с которым вы работаете. То есть даже большие корпорации "делающие" наш интернет вполне адекватно оценивают сложности того или иного подхода. Но всё же дело закончилось тем, что они отменили своё решение, и cross-site cookie продолжат работу, потому что видимо всё же нашлись реальные большие кейсы когда такой подход - верный. И мне кажется чтобы переубедить гугл нужны веские аргументы что вот такой подход (в этом случае часть CORS, даже не весь, о похоронах CORS как жаждет автор статьи речь даже не шла) - необходимая технология.
Чё-то я ваще не согласен. Статья какого-то страшно разгневанного нерда у которого интернет не работает так как ему нравится.
"Соответственно, скрипт может выполнить POST
https://your-bank.example/transfer?to=fungames&amount=1000000000и переправить миллиард долларов на счёт своего хозяина." - нет не выполнит. любой браузер сначала отправит чистый OPTIONS вообще без всяких авторизаций, и если не получит в ответ CORS политику разрешающую и запрос и отправку куки - ни пса он не выполнит."Один из лучших способов в принципе избежать такой проблемы – это отказаться от использования неявных учётных данных." - нифига мне не нравится такой вариант. в таком варианте токен авторизации будет где-то болтаться посреди javascript, где-то его можно будет прочитать из payload и так далее. тогда как cookie можно поставить httponly, и она будет в принципе недоступна javascript. авторизация будет разделена от функциональности и выковыривать её если что надо будет из другого места, если уж удалось заинжектить клиенту вредоносный скрипт.
"Наилучшее решение — настроить на стороне сервера промежуточное ПО таким образом, чтобы оно игнорировало неявные учётные данные при всех межсайтовых запросов." - так можно было бы их вообще запретить в браузере и дело с концом! раз кому-то они так не нравятся. но дело-то в том что они как раз нужны в сложных системах. например есть веб морда какого-то сложного сервиса, который тянет API с нескольких микросервисов, не имеет своего состояния, и использует как раз запросы на микросервисы по другим URL. и вот тут-то всё это склеивается нормально настроеной CORS политикой. для чего она собственно и сделана и в контексте чего отлично работает и все её опции и методы работы понятны. независимо от того что некоторых операторов локалхоста эти все "ненужные" сложности бесят.
ну так принимающая микросхема должна же как-то понимать текущую частоту входящего потока? представьте что в канале тишина, а это постоянно происходит в звуке, при частоте семплов в 44100 в секунду, - огромная часть семплов будет просто пустая. как из стабильного нуля в канале понять с какой он частотой поступает?
определять из первых семплов которые отличаются от нуля? можно, на это нужно примерно несколько десятков семплов по спекам любого DAC. выглядеть это будет как отрезание доли миллисекунды на каждой смене тишина-звук. что в принципе может быть и незаметно, настолько быстро это происходит, но как минимум выглядит как знатный костыль, и конечно же вызовет широкий спектр инфарктов на форумах аудифилов, с вечным проклятием цифрового воспроизведения как неизлечимой ереси.
Нет, это исходит из того что I2S это звук который передаётся с какой-то дискретизацией, 44100, 48000,.. вот эти вот смешные цифры из эпохи mp3, - это частота звукового цифрового потока. и I2S как протокол не подразумевает что эта частота всегда одна и та же, или какого-то соглашения между источником и потребителем о том какой она будет на всё время работы.
Живой пример - вы проигрываете файл mp3 на компьютере mp3 44100, он поступает на DAC как I2S прямо со своей частотой 44100. А потом вы берёте и открываете другой файл, который имеет частоту 48000. Тут возможно было несколько подходов как это могло бы быть сделано:
I2S мог иметь что-то типа SPI входа по которому можно было бы "устанавливать" текущую частоту, которую он как вы выражаетесь "запоминал бы". Но это бы означало внедрение во все чипы I2S какой-то рудиментарной микроконтроллерной логики, довольно дорогое решение для дизайна IC. Причём нужно было бы поддерживать эту логику с двух сторон - источник управляемый проигрывателем ставил бы её, а получатель ожидал. Довольно сложная схема.
I2S мог бы работать на установленной на старте частоте, и тогда бы любой источник должен был бы перекодировать все проигрываемые файлы к этой частоте, что про конверсиях 48000 -> 44100 давало бы "артефакты", ну просто потому что это не 1:2 и даже не какой-нибудь 11:54, - там очень неочевидная дробь, и заодной вызывала бы сердечный приступ и аудиофилов на форумах одним упоминанием "цифровых артефактов перекодировки" (кстати спойлер, - современные устройства практически не дают артефактов. я использую это в хардварном I2S микшере с несколькими входами и мне не удалось услышать ничего что можно и близко назвать искажениями). и это ещё ладно на компьютере, а как бы страшно усложнялись хардварные проигрыватели, где микросхем общающихся по I2S обычно несколько.
I2S мог быть сделан так, что в него всегда поступает опорная частота, и он просто работает на этой частоте разбирая поступающий по другому пину поток с этой скоростью. Меняется частота - меняется скорость, меняются места где ожидаются начала битов. На выходе это всё равно превращается в гладкую аналоговую синусоиду, какая разница с какой частотой там исходная лесенка... По этому пути и пошёл дизайн. Просто, надёжно, дешево.
Да уж, какая-то не впечатляющая интрига вышла... Ведь в даташите любого DAC/ADC на I2S будет написано - либо подавайте опорную частоту на CLKIN, либо конфигурируйте чип на автоматическое выделение опорной частоты из BCK.
Вы так говорите, как будто "оппозиция" это всегда про "свергать правительства". Да и вообще как-то странно это звучит, чтобы вдруг кто-то просто переписывался друг с другом, а их за это надо было бы преследовать нарушая право на частную жизнь. Это ж как в диктаторских режимах чтоли?.. Вот это да!
Срочно пишите всем вокруг эти невероятные новости, надо же всем вокруг доказать что проект с открытым исходным кодом который понятно и доступно, для тех кто в этом разбирается, работает, сделан для того чтобы всех поймать и посадить используя скрытые технологии о которых никому не известно...
signal это же просто мессенджер? как его можно "использовать для смены режимов"? даже если отвлечься от желтушности самой терминологии, это же не платформа для публикаций, не средство для перевода денег, это же просто мессенджер???
суть примерна та же, что и "русский язык используется для смены режимов по всему миру". или "рубли, выпускаемые центрабанком, используются в совершения преступлений по всей России"