AMSL монополисты только в EUV станках, таких станков в Китае нету, их запретили продавать.
В Китае есть станки от AMSL на более старых технологиях, но не только, такие станки делают еще Никон и Кэнон, и в самом Китае уже начинают свои станки выпускать (не EUV).
Компания со штаб-квартирой в Калифорнии, соучредители и инвесторы из США, 3 месяца назад оказывается выпустила антивоенное заявление.
Действительно удивительно)
Внезапно, Clickhouse Inc – это не Яндекс, там иностранный капитал на 300 миллионов и американские соучредители.
In September of 2021 in San Francisco, CA, ClickHouse incorporated to house the open source technology with an initial $50 million investment from Index Ventures and Benchmark Capital with participation by Yandex N.V.[2] and others. On October 28, 2021 the company received Series B funding totaling $250 million at an evaluation of $2 billion from Coatue Management, Altimeter Capital, and other investors. The company continues to build the open source project and engineering cloud technology.
внутри CDN только WebRTC или SRT, от источника публикации это не зависит
а качество не страдает от транскодинга? я когда игрался с WebRTC и Pion у меня сложилось впечатление, что он не заточен под поток высокого качества и там норма выпадение кадров и понижение качества
а CDN же на проверенных линиях, там по идее внутри не должно быть плавающей скорости, нестабильного канала и прочего, для чего делался WebRTC
у Low Latency HLS (который у нас уже реализован, кстати) задержка около трех секунд, что сопоставимо с RTMP и WebRTC over TCP
ну вот, если задержка на проксирование 100 мс (и это большая, она скорее меньше будет), то от 3 сек это будет 3%, не думаю что об этом стоит беспокоится, и насколько понимаю 3 сек это в идеальном варианте, на практике у LL-HLS и 5-10 сек спокойно может быть
и у UDP тоже ведь есть задержка, хотя и меньше, то есть в итоге разница будет еще меньше, порядка 1%
и мы даем не готовое решение, а конструктор. т.е. разработчик может выделить HLS Edge, и уже с него проксировать.
ну я просто говорю, что проблему первого зрителя можно было решить проще, сделав одно место где готовится HLS, вместо вынесения этого на Edge, заодного и нагрузка бы снизилась на Edge
что дает меньшую задержку по сравнению с проксированием HLS
у HLS и так задержка минимум несколько секунд, лишние 100-200мс на проксирование я думаю погоды не сделают
Поэтому нет и оверхеда: Origin работает только на публикацию, Edge — только на раздачу зрителям
Как я понимаю, у вас на Edge ведь горизонтальное масштабирование, то есть разные зрители одного стрима могут быть на разных Edge серверах?
Я про этот оверхэд и говорил, в плане архитектуры – что у вас одинаковая нарезка делается в нескольких местах, а можно сделать в одном.
Или у вас один стрим идет только на один Edge сервер, и все его зрители сидят на этом сервере? Тогда вопрос снимается.
попробуйте, например, разобраться как в нем сделана защита от csrf-атак — там один метот из одного класса, другой метод из другого класса и так во всем.
там валидация в методе Request::validateCsrfToken()
какие еще другие классы?
должно пройти какое-то время для того чтобы заказать этот стрим с Origin сервера, получить его на Edge и приступить к HLS нарезке
не очень понятно, зачем нарезать hls на edge серверах, это же оверхед – будет одна и та же обработка на разных серверах
почему не нарезать на одном сервере (источнике), а edge использовать как прокси, которые будут забирать чанки с этого одного сервера, заодно и не надо будет заказывать поток, можно его проксировать сразу при запросе, и проблем с фризами не будет
SameSite=None
Cookies will be sent in all contexts, i.e. in responses to both first-party and cross-origin requests. If SameSite=None is set, the cookie Secure attribute must also be set (or the cookie will be blocked).
У меня есть фото голых детей. Как моих детей, так и меня самого в детском возрасте и даже фото голых родителей моих, когда они детьми были.
вы отстали от жизни ) почитайте УК, сейчас такие фотки считается за ЦП
Под материалами и предметами с порнографическими изображениями несовершеннолетних в настоящей статье и статье 242.2 настоящего Кодекса понимаются материалы и предметы, содержащие любое изображение или описание в сексуальных целях:
полностью или частично обнаженных половых органов несовершеннолетнего;
несовершеннолетнего, совершающего либо имитирующего половое сношение или иные действия сексуального характера;
полового сношения или иных действий сексуального характера, совершаемых в отношении несовершеннолетнего или с его участием;
совершеннолетнего лица, изображающего несовершеннолетнего, совершающего либо имитирующего половое сношение или иные действия сексуального характера.
Это меняет причину-следствие.
С Sun они стали работать и лицензировать SPARC потому что уже ранее сами разработали RISC процессор. А не сделали RISC процессор, потому что от безденежья пришлось работать с Sun.
То есть у них был сознательный выбор RISC архитекторы и было желание заниматься этим направлением.
Я прочитал интервью Бабаяна, там нигде не говорится, что они готовы конкурировать с Пентиумом, только что там используются схожие принципы суперскалярности, которые они начали разрабатывать как комерческий продукт еще до HP, IBM и Intel (и кстати бывший их сотрудник Пентковский работал над разработкой Пентиума). Что они хотят ставить VLIW Эльбрусы на десктопы там вообще ни слова. Зато есть про Эльбрус-90, который RISC.
Нет, это за «Эльбрус-90микро», это другая линия. Э-90 не суперскаляр, простой RISC, независимая от Е2К вещь.
И еще раз, что они почти всю дорогу занимались и RISC направлением, как раз хорошо показывает, что они не считали, что VLIW универсальный и «подойдет для всего», как говорите вы.
SPARC лицензировали в 1992 году, а RISC процессорами начали заниматься еще в 1986, так что связи тут нет — они изначально развивали RISC направление
В ИТМиВТ Владимир Пентковский принимал участие в разработке суперкомпьютеров Эльбрус-1 (1978) и Эльбрус-2 (1984). В 1986 году он возглавил проект 32-разрядного микропроцессора Эль-90. К 1987 году логический дизайн будущего микропроцессора был завершен, а в 1990г произведены первые прототипы. В Эль-90 сочетались концепция RISC и архитектура Эльбрус-2.
Основные характеристики Эль-90:
выдача до трех команд за такт
32-разрядная архитектура
упрощенный набор команд (по сравнению с Эльбрус-2), большинство команд исполняются за один такт
аппаратная поддержка языков программирования высокого уровня
исполнение по предположению
изменение порядка исполнения команд
предсказание ветвлений
переименование регистров
раздельные кэши команд и данных по 32KB
конвейеризованное устройство вещественной арифметики
поддержка многоуровневой иерархии памяти, кэш первого и второго уровня
поддержка мультипроцессорности (до 10 процессоров)
поддержка отладки, мониторинг производительности
режим «сверхнадежных вычислений» (несколько процессоров независимо производят вычисления и сравнивают результаты, а если результаты расходятся, считают заново). Этот режим требовался, потому что используемая в Эльбрус элементная база была недостаточно надежной для некоторых военных приложений.
В общем советую почитать материалы времен когда Бабаян работал в МЦСТ.
Бабаян в 1992 году основал центр SPARC-технологий, который позднее стал МЦСТ.
Если они всерьез позиционировали Эльбрус как универсальный, зачем тогда основывать центр по RISC технологиям и развивать и выпускать линейки RISC процессоров?
Первый RISC процессор они выпустили еще в 2001.
Но HPC — это лишь часть серверного рынка, причём довольно специфическая, там вообще на GPU переходят часто. А если ваши сервера хостят сайтики — там перформанс Эльбруса будет стремиться ко дну.
Я не думаю, что Эльбрус вообще планировали для десктоп приложений, это случилось скорее вынужденно.
А делали его скорее для вояк и как раз для HPC применений – суперкомпьютеры, симуляция ядерных взрывов (испытания давно не проводят, а считают на суперкомпьютерах), обработка данных радаров раннего обнаружения и прочее.
На одинаковом отрезке работа по отлету от Земли будет больше конечно, сила же больше нужна )
Только оценивать сложность по работе все равно странно.
От Солнца можно лететь на крохотных ионниках, которые экономичные и имеют огромный УИ.
Например с помощью ионного двигателя аппарат Deep Space 1 массой 370 кг увеличил скорость на 4,3 км/с
израсходовав всего 74 кг рабочего тела.
А чтобы стартовать с Земли нужны огромные бочки с сотнями тонн керосина, тут ионники не помогут из-за мизерной тяги.
Так что с Земли улететь намного сложнее )
что сейчас там меньшая производительность, не значит, что так будет всегда
Никон например разрабатывает станки для 5-7нм не на EUV, если бы они считали, что это бесперспективно, то не вкладывали бы в это деньги
AMSL монополисты только в EUV станках, таких станков в Китае нету, их запретили продавать.
В Китае есть станки от AMSL на более старых технологиях, но не только, такие станки делают еще Никон и Кэнон, и в самом Китае уже начинают свои станки выпускать (не EUV).
Компания со штаб-квартирой в Калифорнии, соучредители и инвесторы из США, 3 месяца назад оказывается выпустила антивоенное заявление.
Действительно удивительно)
Внезапно, Clickhouse Inc – это не Яндекс, там иностранный капитал на 300 миллионов и американские соучредители.
In September of 2021 in San Francisco, CA, ClickHouse incorporated to house the open source technology with an initial $50 million investment from Index Ventures and Benchmark Capital with participation by Yandex N.V.[2] and others. On October 28, 2021 the company received Series B funding totaling $250 million at an evaluation of $2 billion from Coatue Management, Altimeter Capital, and other investors. The company continues to build the open source project and engineering cloud technology.
а качество не страдает от транскодинга? я когда игрался с WebRTC и Pion у меня сложилось впечатление, что он не заточен под поток высокого качества и там норма выпадение кадров и понижение качества
а CDN же на проверенных линиях, там по идее внутри не должно быть плавающей скорости, нестабильного канала и прочего, для чего делался WebRTC
ну вот, если задержка на проксирование 100 мс (и это большая, она скорее меньше будет), то от 3 сек это будет 3%, не думаю что об этом стоит беспокоится, и насколько понимаю 3 сек это в идеальном варианте, на практике у LL-HLS и 5-10 сек спокойно может быть
и у UDP тоже ведь есть задержка, хотя и меньше, то есть в итоге разница будет еще меньше, порядка 1%
ну я просто говорю, что проблему первого зрителя можно было решить проще, сделав одно место где готовится HLS, вместо вынесения этого на Edge, заодного и нагрузка бы снизилась на Edge
а если источник в RTMP? или у вас только WebRTC?
у HLS и так задержка минимум несколько секунд, лишние 100-200мс на проксирование я думаю погоды не сделают
Как я понимаю, у вас на Edge ведь горизонтальное масштабирование, то есть разные зрители одного стрима могут быть на разных Edge серверах?
Я про этот оверхэд и говорил, в плане архитектуры – что у вас одинаковая нарезка делается в нескольких местах, а можно сделать в одном.
Или у вас один стрим идет только на один Edge сервер, и все его зрители сидят на этом сервере? Тогда вопрос снимается.
там валидация в методе Request::validateCsrfToken()
какие еще другие классы?
не очень понятно, зачем нарезать hls на edge серверах, это же оверхед – будет одна и та же обработка на разных серверах
почему не нарезать на одном сервере (источнике), а edge использовать как прокси, которые будут забирать чанки с этого одного сервера, заодно и не надо будет заказывать поток, можно его проксировать сразу при запросе, и проблем с фризами не будет
не является, они миноритарные акционеры с 24% акций полупроводникового подразделения Цейса
en.wikipedia.org/wiki/Carl_Zeiss_SMT
а SMIC уже сделали 14нм и тестируют 8нм, и они тоже под санкциями и им не продают EUV
3dnews.ru/1034556/po-kachestvu-proizvodstva-14nm-chipov-kitayskaya-smic-dognala-tsmc
3dnews.ru/1027098/kitayskaya-smic-zapustila-probnoe-proizvodstvo-8nm-chipov-na-tehprotsesse-n1
FF 91.0
3d party куки работают
alanhogan.github.io/web-experiments/3rd/third-party-cookies.html
www.whatismybrowser.com/detect/are-third-party-cookies-enabled
и на странице про куки у мозиллы ничего не сказано, что они их не отправляют, все работает
developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
кто сказал?
сайту надо просто поставить атрибут куки SameSite=None и все так же будет трекиться, как и раньше
и у яндекс метрики он конечно стоит )
вы отстали от жизни ) почитайте УК, сейчас такие фотки считается за ЦП
С Sun они стали работать и лицензировать SPARC потому что уже ранее сами разработали RISC процессор. А не сделали RISC процессор, потому что от безденежья пришлось работать с Sun.
То есть у них был сознательный выбор RISC архитекторы и было желание заниматься этим направлением.
И еще раз, что они почти всю дорогу занимались и RISC направлением, как раз хорошо показывает, что они не считали, что VLIW универсальный и «подойдет для всего», как говорите вы.
Если они всерьез позиционировали Эльбрус как универсальный, зачем тогда основывать центр по RISC технологиям и развивать и выпускать линейки RISC процессоров?
Первый RISC процессор они выпустили еще в 2001.
А делали его скорее для вояк и как раз для HPC применений – суперкомпьютеры, симуляция ядерных взрывов (испытания давно не проводят, а считают на суперкомпьютерах), обработка данных радаров раннего обнаружения и прочее.
Только оценивать сложность по работе все равно странно.
От Солнца можно лететь на крохотных ионниках, которые экономичные и имеют огромный УИ.
Например с помощью ионного двигателя аппарат Deep Space 1 массой 370 кг увеличил скорость на 4,3 км/с
израсходовав всего 74 кг рабочего тела.
А чтобы стартовать с Земли нужны огромные бочки с сотнями тонн керосина, тут ионники не помогут из-за мизерной тяги.
Так что с Земли улететь намного сложнее )