Как стать автором
Обновить
4
0

Пользователь

Отправить сообщение

Формула далеко не такая простая. Проблема в том, что в этой формуле Z, Y и X не известные и далеко не фиксированные.

Просто, чтобы было понятнее с одной стороны меньше пользователей - необходима меньше инфраструктура и соответственно расходы на неё. Но при этом конечный пользователь платит всё-равно больше при меньших пользователях т.к. сотрудники компании не исчезли и их зарплата тоже. При этом же собственно сотрудники и их зарплата тоже далеко не константа и имеет свойство меняться в т.ч. по рыночному движению.

Ну и главное - пример с КиноПоиском оплата каталога идёт предоплатой как правило за год, вот Яндекс заплатили допустим 10 млн. за весь год на права показывать из расчёта стандартной аудитории и её платёжеспособности. Но ввиду ситуации платёжеспособность падает, аудитория тоже, увеличивается себестоимость подписки т.к. оплаченные 10 млн. нужно в любом случае закрыть, плюс ещё бы к концу года накопить на предоплату следующего периода. Да если аудитория падает можно следующий период оплатить из расчёта меньших показов, НО внезапно обстановка нормализуется, пользователи возвращаются и нужно докупать права на объём.

Расширять производство будут, но это расширение может быть только лишь для покрытия "собственных нужд". Всё-таки торговая война с США. Так, что речь вообще не о сию минутных решениях, это долгосрочная стратегия. Также как и долгосрочная стратегия - строительство новых транснациональных интернет магистралей компанией Huawei, тем самым набирая международное влияние на рынке.

Цены сервисов складываются не только из зарплат сотрудников компании, владеющей сервисами. Есть ещё инфраструктура, требующая поддержки и расходников и прочие расходы. А также если сервис условно КиноПоиск, включается ещё учёт годовых/квартальных выплат владельцам каталогов (причём в формате предоплаты). Ну и главное нужно не забыть поделить получившиеся расходы на хотя бы усреднённое ожидаемое число Пользователей сервиса, готовых платить. Если их будет меньше, стоимость сервиса конкретному конечному пользователю также будет выше.

Вы же сами в статье указывали, что Китай вероятнее всего будет отдавать предпочтение собственному рынку. Так вот это предпочтение если и будет, то явно шире только производства - продажи так же будут приоритетны внутри. И у Китая есть собственный крупный игрок Huawei с огромной прожорливостью и амбициями.

Это я к тому, что у Китая свой рынок, а его контрагенты уже заняты.

47 порталов обращаются к различным API федерального портала Госуслуг (ЕСИА и другие). Т.е. сама реализация и поддержка электронного правительства на gosuslugi.ru и Ростелекоме, но вот сами порталы реализуются самостоятельно.

Т.е. это типовое решение касается только API для интеграций и единой системы взаимодействия с ведомствами. Собственно сертификат, о котором шла речь в статье нужен был для авторизации на этих API федерального портала.

Более того это типовое решение допускает отсутствие регионального портала т.к. набор услуг, привязанный к региону в данной системе так же доступен на gosuslugi.ru при выборе соответствующего региона.

Если просто говорить gosuslugi.ru это общий бек и фронт, но ряд регионов также сделали свои фронты. И у некоторых вероятно есть услуги отрабатываемые не через эту единую систему (например у Москвы). Нужно отметить, что Москва тут исключение, они запустили свой портал раньше федерального.

В общем такие проблемы зависят от региональной реализации портала, если такой имеется.

Ну тут в названии министерства уже закрались подозрения, ладно если бы "Министерство цифрового развития и связи", но там ещё и транспортные проблемы решают...

наше государство не едино и что там в регионах творится - всем похрен

Хотите верьте, хотите нет, но так и есть. В этом и суть каждая область обособлена до определённой степени, имеет возможность делать в этих рамках всё что хочет без особых согласований с правительством страны. И точно также самостоятельно несёт всю ответственность за свои ошибки.

Я надеюсь вы же не забываете, что у нас федерация, что как бы подразумевает деление на несколько управленческих уровней со своей степенью своботы принятия решений - глобальный/федеральный, региональный, областной и т.д.

Если данная проблема вызовет достаточной шумихи (информация дойдёт до нужного уровня) с ними будут разбираться иначе нет.

Ещё раз повторяю это не форк, просто по тому, что если бы это был форк, то и весь интерфейс был бы не похожим, а один в один, было бы указание и на Минцифры и на Ростелеком непосредственно на сайте и т.д. т.п. То, что муниципальный портал Госуслуг взял логотип федерального и приписал внизу про муниципальность ещё не значит их прямой связи.

Более того, даже канал обратной связи на муниципально портале не подразумевает почтовый ящик. Имеется только модальное окно с формой.

Также федеральные Госуслуги, Госуслуги Московской области и Госуслуги Москвы все на контейнерах основаны (всё в Docker/Kubernetes). У Госуслуг Пензы контейнеров нет.

Но ведь email, телефон, СНИЛС, полный номер паспорта, логин и т.п. это идентификатор пользователя и он очевидно публичный всегда в любой системе. Электронная почта вопреки утверждению @DabjeilQutwyngoне является секретной по своей сути.

А вот чтобы аутентифицировать пользователя по данному идентификатору и требуется проверочный фактор одного из типа (я знаю, я имею, я обладаю). Обычно пароль, но может быть OTP, клиентский сертификат, подпись электронным ключом и т.п.

Для повышения безопасности применяют множество факторов (для авторизации некоторых операций требуется множественная аутентификация/повышение доверия). Тут тоже нужно понимать, что каждый фактор по сути несёт разный уровень доверия и, что нельзя проверять повторно уже проверенный фактор (по тому, что логично смысла и толка в этом нет).

Есть вариант при использованием сертификата или электронного токена (резидентный/обнаруживаемый ключ) не передавать идентификатор в процессе аутентификации, однако он всё же будет существовать - публичный ключ или отпечаток сертификата.

В целом у ДИТ Москвы используют вполне классическую систему аутентификации, такуюже как и здесь на Хабре. А вот относительно ЕМИАС действитель, когда для доступа требуется ввести номер ОМС как идентификатор, а для аутентификации просят ввести месяц+год рождения при том, что эта информация имеется в номере ОМС. Тут конечно действительно безопасности ноль.

Нужно ещё понимать, что большая часть пользователей ещё нуждается в повышении цифровой грамотности, а также у нас имеются определённые сложности/ограничения относительно электронных токенов (этот вопрос уже касается контроля федеральных служб).

Всё-таки схема: Идентификация -> Аутентификация -> Авторизация. Я есть, вот мои доказательства, хочу сделать...

Минцифры очевидно отвечали относительно Федерального портала Госуслуг (gosuslugi.ru), а не gosuslugi.pnzreg.ru, чьи исходники утекли. За Федеральный портал они отвечают, хотя подрядчик Ростелеком. А вот за портал Госуслуг Пензы Минцифры не отвечают и вполне могут даже не знать о его существовании. Минцифры не капались по тексту статьи и не разбирались с фактами - написано Госуслуги, они и произвели проверку по gosuslugi.ru, результат опубликовали.

https://gosuslugi.pnzreg.ru/ это прям самые обычные госуслуги, только похоже на форк, со своей репой, со своими тасками в редмайн, своей базой и своими интеграциями с платежкой

Увы gosuslugi.pnzreg.ru не относятся к Федеральным Госуслугам gosuslugi.ru, которые разрабатываются и поддерживаются Ростелекомом. Это даже не форк т.к. gususlugi.ru не используют Битрикс и куда более сложнее как внутри, так и качественнее выполнены в интерфейсе.

Это такой же самостоятельный и не зависимый в глобальном смысле проект, как госуслуги на Mos.ru, MosReg.ru, Госуслуги Санкт-Петербурга и все остальные. Единственная связь с Федеральными это применение входа через ЕСИА и взаимодействие с их API.

Более того, на gosuslugi.pnzreg.ru даже не указано, кем поддерживается портал. По идее это должно быть IT подразделение муниципалитета Пензы, если оно конечно существует...

ноги растут именно про мос_ру

Для того, чтобы узнать откуда на самом деле ноги ростут и был задан вопрос про git remote.

Может кто ещё разберётся в этом всём.

Правлю свою ошибку про *.mosreg.ru, не могло от туда утечь т.к. отношения Пензы к Московской области ни какого.

Вы качали архив? Если да, то сразу вопрос: всё-таки какой домен указан в remote? git.mos.ru или mosreg.ru или pnzreg.ru или совсем другой? Это важно как минимум с точки зрения проверки самой статьи, которая и так полна неточностей.

Так уверенно указывать название "Госуслуги" без конкретизации региональности в заголовке явно манипуляция, у нас же ведь все госуслуги (очевидно же их много) делают одни и те же команды и управляются они наверное все тоже одной компанией.

Не говоря уже о том, что муниципальные ресурсы Пензы не имеют ни какого отношения к Департаменту Информационных Технологий Москвы. Однако в статье применили ссылку на доменную зону *.mos.ru (ещё и с ошибкой). Даже если бы данный портал разрабатывал и поддерживал ДИТ по какому либо контракту и исходники были действительно на git.mos.ru, стек технологий был бы явно другим. Уж ДИТ то давно использует и Node.js и Rust и Go и всё остальное, тот же фронт mos.ru на Next.js.

Одни манипуляции, чтобы придать значимости находки папки .git. Не то, чтобы проблемы нет, но она явно не того уровня, как если бы это был исходный код федеральных госуслуг или Московских (не региональных).

Ещё и удивление, что ЕСИА это OpenID, который как бы один из стандартов IdP, у Сбера тоже так то вход SberID это OpenID. Про донаты относительно OpenID вообще отдельная речь, донаты на открытую спецификацию...

Это всё притензии к статье, а к вам только как ответ на "не читал/качал, но осуждаю". По информации в статье всё и так понятно как обстоят дела.

Ладно Хабр, но статья в этом же виде форсится везде и люди далёкие от разработки совсем по другому воспринимают данный текст. И то, что Федеральные Госуслуги дырявые и что они как-то связаны с mos.ru, а значит и Московские тоже дырявые. В целом любые Госуслуги дырявые, это же "Госуслуги".

Что самое забавное, наверное фидбек о проблеме улетел не в Госуслуги Пензы, а в Федеральные Госуслуги (Ростелеком). Что как бы совсем разное.

Скорее всего всё-же утекло с *.mosreg.ru, всё-таки там даже Traefik Dashboard светится...

Это просто эксперимент, ровно такой же как и тысячи других в публичных и во внутренних командах Google по типу тех, что делаются в X Development, Area 120, ATAP, Jigsaw.

Как уже написал@Lelant0sсейчас это естественная конкуренция продуктов (понятно, что на данный момент перевес в сторону Android), плюс попытка сделать более лёгкую универсальную платформу для устройств.

По своей сути можно сравнить с тем, как Microsoft начали разрабатывать с нуля Windows 10X, которая в итоге так и не вышла на устройствах и как проект уже закрыта, но её код уже влит в Windows 11 (Отсюда кстати внешних изменений у Windows 11 мало, но они именно из Win10X и отсюда же отсутствие обратной совместимости местами или утеря некоторого функционала).

Правда есть весомое отличие с приведённым примером - Fuchsia рассматривается как самостоятельная система без перспективы слияния с Android (во всяком случае сейчас).

Потенциала и надежд много, отношение достаточно серьёзное к проекту. Главное чтобы проект смог себя окупить в экономическом смысле. Хотя в крайнем случае фуксию спокойно передадут сообществу, для этого всё сделано.

Относительно тривиальных типов (string, int, etc.) в третьей версии protobuf при указании optional можно получить nullable (в Golang будет сгенерировано в *string, *int, etc.). Можно ещё чуть костыляво делать через oneof, если вдруг генераторы не поддерживают optional (по типу Twirp).

А вообще действительно protobuf немного не логичный в этом плане т.к. в 3-ей версии все поля считаются опциональными, но есть ещё флаг optional, который влияет на генерируемый код. Возможно относительно скоро станет по лучше т.к. в исходниках уже появилось упоминание 4-ой версии.

Относительно самого gRPC он на самом деле не прибит к protobuf жёстко, можно поставить кодек хоть под Apache Thrift, хоть JSON, хоть MsgPack, да любой формат в целом.

Да и к транспорту по сути gRPC тоже не прибит. Например, не потоковые вызовы можно на прямую пробросить с HTTP/1.* просто подменив номер версии на HTTP/2 (это в Golang). Или можно переложить gRPC на Quic/HTTP/3 (да кода готового нет и его нужно написать).

Тем не менее - самое главное чтобы клиент знал особенности сервера. А gRPC по сути описывает формат взаимодействия (обычные/потоковые методы), это только набор соглашений.

Относительно REST у gRPC есть grpc-gateway и расширения в protobuf с которыми можно реализовать по мимо gRPC ещё и REST (как и делает сам Google). Для этого даже есть генератор схемы OpenAPI из proto файлов.

Это всё к тому, что gRPC обычно рассматривают с одной стороны. По факту даже все фичи кодогенерации к gRPC на прямую не имеют отношения, это скорее часть Protocol Buffers, чем gRPC как таковой.

В любом случае для применения той или иной технологии нужно взвешивать все за и против. Тот же GraphQL тоже нужно уметь и знать как использовать и главное где использовать.

P.S.: Так если посмотреть HTTP по своей сути тоже можно отнести к RPC, только с ограниченным набором методов GET/POST/etc. и с упором на адрес ресурса.

Чуть ошибочка вышла, всё же правда Spotify ID это Base62 представление 128-битного Spotify GID. В любом случае, что так 22 символа, что так со 128-битным идентификатором внутри.

Интересно, что Spotify Codes по факту хранят не Spotify Global ID размером 128-бит, а Spotify Scannable ID (media-ref) размером всего 37-бит.

Т.е. на данный момент решение работает, однако явно не может быть применено для линковки всего пространства Spotify GID и вероятно в будущем потребует обновления. С другой стороны покрытия прям всего пространства Spotify GID и не требуется т.к. необходимо линковать только плейлисты, альбомы, треки, подкасты, эпизоды.

Кстати поправлю данную статью Spotify Global ID в API кодируется не в base62, а в base58. Base58 представление официально называется Spotify ID.

Во-первых http уже давно поддерживает мультиплексирование. HTTP/2, не?

Не, это такое же мультиплексирование как мультизадачность на одноядерном процессоре в один поток. И самое интересное, если у вас внезапно произойдёт потеря пакета все потоки будут пересылаться (мы же поверх TCP) с самого начала, что будет хуже чем если бы у нас было классическое одно TCP соединение на один поток, как это было всегда в HTTP/1.x.

Собственно HTTP/3 это своего рода переезд HTTP/2 с TCP на UDP. QUIC тут изначально был как прослойка, добавляющая много чего из мира TCP (мы же хоть и махнули в сторону мультиплекса, по прежнему опираемся на ряд механизмов из TCP) с рядом улучшений и приправ на будущее. Уже ближе к тому времени как QUIC попал под крыло IETF он стал восприниматься как более универсальный и самостоятельный уровень.

H/3 зависит от QUIC, но QUIC от H/3 не зависит. А соответственно есть возможность поверх QUIC применять любые другие протоколы, хоть DNS пакеты гонять, хоть RDP, хоть игровые, хоть MPEG потоки. Собственно протокол WebTransport по своей сути просто идентификатор "протокола", по факту весь WebTransport это и есть весь QUIC.

Про решение проблем только монополистов классика конечно же... Я например, решил тоже попробовать и даже знаю какую проблему QUIC решит, которую HTTP/2 не решит. Например, для стриминговых сервисов (это может быть аудио/видео/стриминг игр/приложение да чего угодно - не важно). Я могу в рамках одного соединения QUIC получать медиаконтент (например будем гонять MPEG-DASH совместимое видео) и одновременно контролировать со своей стороны битрейт (не переключаясь, не открывая новые соединения и т.д.), а ещё могу в третьем потоке сразу получать какие-то данные по интерактиву (в случае игр состояние и т.д., в случае потокового вещания например голосование на экране).

Как разработчик игры, я могу использовать соединение QUIC и уже сразу скинуть с себя задачу по шифрованию / базовому контролю соединения. Я буду думать только о формате пакетов и возможно о синхронизации какого-то состояния.

Ок, а может я хочу в одном соединении сразу проксировать и DNS трафик например и HTTP/1 или другой не шифрованный трафик и чтобы это всё ещё дополнительно шифровалось. Я просто поднимаю соединение QUIC и в разных потоках оперирую разными протоколами. Для меня в данном случае поток QUIC всё равно, что обычный UDP, разве что ещё сразу зашифрованный.

Или например будущий потенциальный этап развития gRPC, сейчас он основан на HTTP/2. Вероятно его переведут на HTTP/3 или ещё лучше на чистый QUIC. Тогда у нас не будет проблемы с глобальными просадками в случае потери одного пакета. Точнее проблема будет касаться только одного потока, но не всего соединения и не всех потоков в этом соединении.

Для всего можно найти и придумать применение, то что вы с этим не встречаетесь, не значит, что с этим не встречаются другие и тем более не значит, что с этим встречаются только "монополисты".

Состояние half-open относится к TCP, в UDP соединениями в состоянии "half-open" можно считаться те, у которых нет обратного трафика. Опять таки в самом UDP нет такого понятия как half-open. QUIC построен поверх UDP, соответственно весь базовый мониторинг должен касаться именно UDP.

Далее у QUIC тоже нет понятия "half-open", есть только "half-closed" и то это относится к потокам в QUIC. Причём потоки в QUIC работают внутри уже установленного соединения (сессии QUIC).

Ок, вам как оператору нужны метрики по QUIC, используйте существующий формат логирования для QUIC и HTTP/3 - qlog. Не поверите, но инструменты мониторинга и отладки уже придуманы или прорабатываются.

Лежит это всё рядом с RFC 9000 в рабочих черновиках и не только. Нужно всего лишь как минимум посмотреть документы рабочей группы QUICWG.

Есть такие документы как:

Т.е. существуют документы и по самому протоколу, по вспомогательным элементам протокола таким как QPACK, использование TLS вместо QUIC Crypto, балансировщикам. Есть документы для операторов Applicability & Manageability. Есть документы по расширениям, например тот же qlog, используемый для отладки. Нужна визуализация, не проблема - qvis.

Да QUIC получается более закрытым протоколом по отношению к посредникам, если вы не являетесь условно доверенным лицом одной из стороны обмена данными (а значит у вас вероятно нет доступа ни к qlog ни к другой внутренней и зашифрованной кухне протокола). Но это и к лучшему, а для посредников, обеспечивающих работоспособность соединений и т.д., а не внедрение и прослушивание потока - вся работа остаётся только в рамках IP/UDP.

Главное изменение Windows 11 по сравнению с прошлыми версиями это более лёгкое ядро с поддержкой x64 и ARM64, созданное с нуля в рамках эксперимента Windows 10X. Собственно Windows 11 и есть Windows 10X, а не Windows 10. Интерфейс Windows 10X (теперь Windows 11) делался по подобию Chrome OS.


Похоже, что майский билд 21376 стал первым переходным на новое ядро (Win10 to Win10X).

У меня Windows 11 пришла штатно по Insider Preview (Dev), установилась без вопросов. Система работает стабильно без каких-либо проблем. Сообщения о несовместимости с минимальными требованиями нет и не было, хотя процессор (i7-6700K) в список совместимых не входит. Так, что Skylake для Win11 вполне хватает.

Информация

В рейтинге
4 321-й
Откуда
Зеленоград, Москва и Московская обл., Россия
Зарегистрирован
Активность