всё ещё не знаю как в Homebrew, но после обновления арча все релевантные пакеты из AUR нужно обязательно пересобрать.
Я в "своём" пакете в brew на такое не натыкался, но, насколько помню, это решается явным PR с изменением ревизии, чтобы зафорсить пересборку новой версии пакета. То есть так же как и в AUR.
Как в таких условиях менять политику AUR, мне не очень понятно
На мой взгляд, тут всё просто - если ты используешь AUR то ты должен _один раз_ принять на себя все риски его использования. То есть риск возникает не в момент установки очередного пакета, а в момент установки ПЕРВОГО пакета из AUR. После этого у тебя нет пути назад.
Как следовало бы изменить политику:
добавить условный yay (или любой другй AUR-менеджер) в основной реп и объявить этот пакет официально поддерживаемым (именно сам пакет yay, но не AUR-пакеты, которые через него ставятся)
установку этого пакета считать акцептом рисков (можно даже добавить ради этого отдельный ключ в CLI)
очень спорный момент, который никогда не будет реализован, но я бы просто добавил AUR в pacman, и ставил пакеты через `pacman -S aur/something` с явным флагом "принять все риски". И уже тогда обновления через `pacman -Suy` обновляли бы все пакеты: и AUR и обычные
В целом, за то, чтобы дать удобство людям, которые хотят осознанно использовать AUR и понимают и принимают все риски этого использования.
Я вот сейчас ради интереса зашёл в официальную вики про AUR (https://wiki.archlinux.org/title/Arch_User_Repository). Обратите внимание на описание установки пакетов. Напомню, мы в 2026 году живём, а не в 2006. В 2026 обычно не нужно качать описания пакетов и тарболы с сорцами руками. Причём, на этой странице всё же есть в Related и ссылка на AUR helpers, спасибо хоть за это.
Мне тут непонятна именно эта двойственность подхода - с одной стороны мы описываем AUR в официальной вики и в целом его поддерживаем. Но с другой - не даём никаких штатных удобных механизмом его использовать. Как так? Почему такая шизофрения в отношении?
Насколько я смог понять из гугла, обновления в core и cask обязательно проходят через мейнтейнеров в виде пулл-реквестов на гитхабе, что абсолютно не похоже на AUR
Да, всё через PR делается. А в чём разница с AUR? Ни там ни там нет на самом деле никакого контроля над тем, что именно пушится. В Homebrew любой может добавить свой пакет и залить туда всё что угодно. Да, кто-то этот PR будет аппрувить, но никто же не в сам код.
Я одно время "мейнтейнил" пакет в brew и весь аппрув там - это просто формальность.
Почему-то есть подозрение, что вы перепутали с do-release-upgrade
Да, вы правы, посыпаю лысую голову пеплом. Именно dist-upgrade на серверах у меня ничего не ломал
Сервера тоже разные бывают. До недавнего времени я вообще не мог использовать Ubuntu без PPA (про дебиан не знаю) потому, что там вообще не было OpenZFS, а докер был настолько замшелой версии, что это просто стыдно.
Не так давно ситуация поменялась и OpenZFS появился в официальном репе. А вот с докером беда так и осталась - приходится всё-равно добавлять сторонние PPA, а если так, то о какой стабильности вообще идёт речь.
Если забыть про докер, то в LTS уже изначально идёт люто устаревший софт. Это возможно было нормально когда весь софт компилировался под конкретный дистр с кучей дистрозависимых патчей и поставлялся в бинарниках. Но сейчас, когда огромная часть софта написана на скриптовых языках, жёстко завязана на версию рантайма и зависит от кучи сторонних библиотек, такой подход тупо не работает.
Это в любом случае вынуждает либо подключать PPA для получения более новых версий, либо вообще использовать nvm и npm, venv и rvm. Всё это идёт вразрез с философией дистрибутивов (не только Ubuntu). Более того, сам концепт "стабильных" дистрибутивов в этом месте ломается и никакого решения, кроме контейнеризации, нет.
Не очень понятно, как вы собрались менять политику AUR, если он наполняется абсолютно левыми людьми, которые могут делать (и, что ещё хуже, не делать) что хотят
Да и пусть делают что хотят. По похожим правилам существует Homebrew, например. И ничего - нормально всё. Честно, у меня доверия к нонейм-мейнтейнеру из "команды" арча не больше чем к такому же нонейм-мейнтейнеру случайного пакета из AUR: и там и там может прилететь бяка и и там и там надо так или иначе принимать риск.
Немного отвлечённо, но я жду момента когда можно будет вообще избавиться от мейнтейнеров и исключить их из цепочки разработчик -> пользователь. Это лишнее звено, которое не приносит абсолютно никакой пользу, зато приносит риски.
Сломанные правила apparmor, из-за которых часть приложений тупо не запускается, виртуалбокс портящий память внутри виртуалок, сломанный питон с утечкой памяти, снос видеодрайвера после простого apt dist-upgrade...
Я уже зарёкся делать dist-upgrade. Это всегда тонна багов, которые и вылазят и вылазят и вылазят в будущем после обновления. Да, полагаю, что мне сейчас многие скажут что у них всё работает. Верю (неохотно). Но у меня это нормально не работало ни разу: ни на серваках, где вообще кроме докера считай ничего нет, ни на десктопе. Всегда потом (а то и сразу) вылазят проблемы.
Таким образом ключи будут обновляться раз в неделю.
На это у меня есть два вопроса:
Почему это не включено по умолчанию?
Зачем мне обновлять ключи чаще, чем я обновляю систему? Если всё настолько ушло далеко вперёд, что обновились даже ключи archlinux-keyring, то ок - я ССЗБ и буду страдать. Но несколько месяцев между обновлениями - это вообще не срок
В арче есть несколько довольно странных решений, которые почему-то не хотят исправить и сделать более удобным для юзера.
В основном, конечно, претензии к политике по отношению к AUR. Как по мне, нужно:
добавить пакадж-менеджер для AUR в основной репозиторий. Как же замучало каждый раз разбираться со сборкой yay, которому в очередной раз не нравится версия libalpm. Сделал pacman -Suy вместо yay -Suy и привет
изменить политику по отношению к AUR - это должна быть часть основной инфраструктуры. Сейчас к нему официальное отношение Арча примерно как к сборищу бомжей под мостом, которые норовят тебя ограбить и изнасиловать. Отсюда миллион подтверждений при попытке установки любого пакета через тот yay или почивший yaourt и другие
собственно, выбрать какой-нибудь PM для AUR и назвать его официальным
Но в с pacman не всё гладко: не понимаю что мешает починить проблему с archlinux-keyring - всего-то нужно, чтобы pacman -Suy (обновить все пакеты) сначала обновлял archlinux-keyring, а уже потом всё остальное.
Сейчас, если пару месяцев не обновляться, то у части мейнтейнеров пакетов обновятся ключи, а может и появятся новые мейнтейнеры. Далее мы делаем pacman -Suy и он радостно в каком-то своём порядке начинает качать пакеты, проверять их подписи, а они не совпадают с теми, которые сохранены в системном keyring (он же уже устарел к этому моменту).
Что делает pacman? Нет, он не обновляет archlinux-keyring перед обновлением всего остального, что полностью решило бы проблему, и не советует его обновить тебе самому, и вообще его нигде не упоминает правильное решение. Вместо этого он предлагает абсолютно ошибочное и неработающее решение - вручную добавить ключ мейнтенера в свой keyring. Это никак не помогает, а делает только хуже.
Наверное, настоящие арчеводы обновляются каждый день и даже не знают о существовании этой проблемы, но она живёт десятилетия, она постоянно плодит вопросы на форумах и она потратила, наверное, миллионы человекочасов у разных пользователей на своё решение. А ведь исправление заняло бы примерно 5 минут, но...
Давно использую арч на домашнем сервере, но уже принял решение перейти на Ubuntu. Замучали постоянные мелкие проблемы: правда, в основном они касаются докера - то он вообще не работает при установке определённой версии, то перестаёт работать автоматический рестарт контейнеров после ребута (это вообще загадочная проблема, которая попила немало крови, потому что заметить её заранее невозможно), то он перестаёт работать поверх zfs. В Ubuntu хватает своих проблем, но по совокупности всё же она для меня выигрывает.
Простите, накипело. Просто нужно было выговориться, а тут внезапно кто-то упомянул арч :)
Читал и проверял. И даже обнаружил, что описанный метод всё ещё работает на мегафоне для домена szfwp.megafon.ru. Он действительно обогощает заголовки запроса и добавляет X-IMSI, X-SGSN, X-IMEISV, X-3GPP-USER-LOCATION-INFO и X-MSISDN - проверяется простой подменой Host.
Но ни один из перечисленных в статье доменов так себя не ведёт, по крайней мере если запрашивать корень. О чём я и написал
Вот именно это я и проверял до того как написать свой первый комментарий. Если это и работает, то помимо домена нужен какой-то ещё маркер: специальный путь, или заголовок, или ещё что-то такое. Одного домена тут явно недостаточно
Если он не добавляет эти заголовки в ответ клиенту, то как MAX их получает?
Ваше объяснение не согласуется само с собой:
cleartextTrafficPermitted включен только для доменов операторов, но не для доменов MAX'а, то есть клиент MAX'а не сможет сделать http:// запрос на свой сервер, а значит, ОПСОС не сможет добавить в него никакие хедеры, а значит сервер MAX напрямую эту информацию от ОПСОСов получить не сможет
То, что внутри инфраструктуры оператора в запросы добавляются служебные хедеры - возможно, но вопрос в том, каким образом эта служебная информацию должна попасть в клиент MAX?
Делает HTTP-запрос (открытым текстом) на оператор-ный эндпоинт.
Оператор на своём оборудовании дописывает в заголовки ваш MSISDN (номер телефона).
Сервер MAX видит заголовки → знает, кто вы. Без SMS-кода.
Я попробовал на Мегафоне, МТС и Билайне - позапрашивал через них соответствующие домены через HTTP и в ответ не получил никаких странных хедеров (единственное что подозрительное нашлось - кука cookiesession1 от idgw.mobileid.mts.ru .
Ещё непонятен момент про Header Enrichment: зачем он нужен, если мы всё-равно запрашиваем эндпоинт самого оператора, ведь он в ответ может со стороны сервера без каких-то дополнительных манипуляций добавить в ответ нужные данные.
В общем, буду благодарен, если распишите этот момент более подробно
Зависит от провайдера, но в Москве сейчас MTProxy банится на ТСПУ как протокол у многих. Неважно на какой именно сервер вы подключаетесь - в РФ или нет.
ТСПУ ловит какой-то маркер в рукопожатии и всё соединение после этого идёт лесом.
И да, это касается именно последней версии Телеграма и EE-режима. Причём, если у вас включен режим с фоллбеком на собственный https-сервер с валидным сертификатом, то обычные https:// запросы из браузера и курла на этот же сервер и на этот же 443 порт проходят без проблем. Палится именно хендшейк mtproxy и палится мгновенно. Это не probe и это не блеклистед IP, просто РКН нашёл какой-то очень качественный маркер в самом трафике и использует его
Напрямую получить состояние сетевых интерфейсов они, конечно, не могут. Зато могут поотправлять запросы на домены из разных зарубежных зон и посмотреть под каким IP вы туда ходите. Если на ya.ru вы зашли из РФ, а на some-metric-tracker.io - из Нидерландов, то тут явно что-то нечисто, а значит, надо ваш нидерландский IP слить в РКН, который радостно заблокирует к нему доступ из РФ.
А если ещё вспомнить про я.метрику, которая есть но почти всех российский сайтах, то становится понятно, что от этого точечно не защититься
Не забывайте про браузер и сайты с я.метрикой (а это процентов 95 от всех русскоязычных сайтов). Придётся ведь и за этим следить. И простого разделения на .ru-домены, которые ходят напрямую, и все остальные (ходят через зарубежье) тут недостаточно т.к. сайт (или метрика) в любой момент может запросить трекалку с домена .com и получить ваш "внешний" адрес
Отличная работа с технической точки зрения. Но с практической гораздо удобнее использовать распознавание внезапно регистрационных номеров: расстояние не так критично, наложения нескольких сигналов нет и точность сильно выше
Я смотрю на всё это и не вижу вообще никакого долгосрочной стратегии. Зато вижу постоянные подмену целей средствами. Детали реализации становятся целями и KPI. А про истинные цели (если они и были) все уже давно забыли и сейчас по факту борются с собственным народом.
На мой взгляд, возникла парадоксальная ситуация: за эти годы с 2022 народ уже привык к внешним и внутренним ограничениям и свыкся с ними. На момент 2024 и начало 2025 года я наблюдал, что обычные люди в массе своей поддерживали власть и были готовы терпеть и дальше. Эту поддержку не уменьшал ни телеграм, ни отсуствие MAXа, ни мобильный интернет. Но тут пришёл некий приказ свыше и власти, руками РКН, начали рубить всё подряд без разбора. Что сделал народ? Начал бороться с РКН. Начал каждый день ждать новой подлянки. Начал обмениваться средствами обхода. Начал задавать вопросы.
И вот прошло 1.5 года активной борьбы РКН со здравым смыслом. И что я вижу сейчас среди обычных людей? Вижу полнейшее отсутствие доверия и поддержки к власти, в т.ч. среди "глубинного" народа. Очень показательна история с МАКСом - любая бабушка уверена, что это какая-то очередная подлянка и скам, который будет за тобой следить.
Самое смешное, что никому извне и изнутри (вспомним все истории с болотными и т.п.) за все эти годы не удалось сделать того, что всего за один год сделала сама власть руками РКН. Я даже затрудняюсь сказать как это назвать - несусветной глупостью или целенаправленным саботажем. Долгое время обычный народ защищал свою лодку от раскачивания, однако сейчас власть просто вынула пробку из дна.
"Планировать" происходит от "план" - ряд предварительно обдуманных действий, мероприятий, объединённых последовательно для достижения цели с возможными сроками выполнения (с) запрещённая вики
Скажите, меня одного корёжит от подачи новостей в таком формате?
По информации портала «Код Дурова», мессенджер WhatsApp начал рекомендовать российским пользователям задействовать альтернативные сетевые подключения, например, VPN для обхода блокировок.
Я понимаю, что хороший тон - дать ссылку на источник, но почему нельзя самому взять и перепроверить? Буквально сделать один тап в телефоне и увидеть там то самое сообщение. И, похоже, все "новости" на хабре от самого хабра оформляются именно в таком стиле - описывается не сама новость, а новость о появлении новости в каком-то стороннем источнике. Будто новостной редактор хабра вообще не субъектен
Может быть, конечно, но я предварительно сходил к ним на сайт, посмотрел как он выглядит и сравнил со скринами приложения - они похожи по цветам, но контролы все разные, да и лейаут другой, более заточенный именно под мобилки. В общем-то, мне и по тексту показалось, что они всё делали с нуля
Я понял так, что существует много людей, которые ненавидят FreeCAD
Полагаю, вы в том числе и про меня, поэтому считаю нужным ответить: слово "ненавидят" не очень подходит. Это же не какая-то слепая ненависть, а аргументированная позиция людей, которые реально использовали или пытались использовать FreeCAD. Основная претензия к FreeCAD у всех, кого я знаю - это не то, что он чего-то не умеет или что на нём что-то невозможно сделать. В плане возможностей он как раз вполне хорош и я тоже видел в том же ютубе отличные сложные проекты, сделанные в нём. Настоящая его проблема - это глючность и падучесть. Пока у вас один скетч - всё хорошо и быстро работает, вытяжка вытягивает, фигуры вращения вращаются. Но с ростом сложности начинают появляться падения, начинаются лаги и глюки. И чем сложнее становится проект, тем чаще он падает и к тем бОльшим последствиям приводят глюки. Этим можно пользоваться, если нет альтернатив, но это нервы и трата моральных сил на бессмысленную борьбу.
Немного вернусь к изначально теме статьи и поддержу автора в его работе. У меня и самого давно была мысль сделать нечто подобное, но, честно говоря, я не поверил в свои силы и даже не начал. Поэтому немного завидую и желаю всяческих успехов. Реально такого продукта не хватает!
Я в "своём" пакете в brew на такое не натыкался, но, насколько помню, это решается явным PR с изменением ревизии, чтобы зафорсить пересборку новой версии пакета. То есть так же как и в AUR.
На мой взгляд, тут всё просто - если ты используешь AUR то ты должен _один раз_ принять на себя все риски его использования. То есть риск возникает не в момент установки очередного пакета, а в момент установки ПЕРВОГО пакета из AUR. После этого у тебя нет пути назад.
Как следовало бы изменить политику:
добавить условный
yay(или любой другй AUR-менеджер) в основной реп и объявить этот пакет официально поддерживаемым (именно сам пакетyay, но не AUR-пакеты, которые через него ставятся)установку этого пакета считать акцептом рисков (можно даже добавить ради этого отдельный ключ в CLI)
очень спорный момент, который никогда не будет реализован, но я бы просто добавил AUR в pacman, и ставил пакеты через `pacman -S aur/something` с явным флагом "принять все риски". И уже тогда обновления через `pacman -Suy` обновляли бы все пакеты: и AUR и обычные
В целом, за то, чтобы дать удобство людям, которые хотят осознанно использовать AUR и понимают и принимают все риски этого использования.
Я вот сейчас ради интереса зашёл в официальную вики про AUR (https://wiki.archlinux.org/title/Arch_User_Repository). Обратите внимание на описание установки пакетов. Напомню, мы в 2026 году живём, а не в 2006. В 2026 обычно не нужно качать описания пакетов и тарболы с сорцами руками. Причём, на этой странице всё же есть в Related и ссылка на AUR helpers, спасибо хоть за это.
Мне тут непонятна именно эта двойственность подхода - с одной стороны мы описываем AUR в официальной вики и в целом его поддерживаем. Но с другой - не даём никаких штатных удобных механизмом его использовать. Как так? Почему такая шизофрения в отношении?
Хм. Это для новых установок? На старых я не далее как месяц назад в очередной раз поймал именно эту проблему
Да, всё через PR делается. А в чём разница с AUR? Ни там ни там нет на самом деле никакого контроля над тем, что именно пушится. В Homebrew любой может добавить свой пакет и залить туда всё что угодно. Да, кто-то этот PR будет аппрувить, но никто же не в сам код.
Я одно время "мейнтейнил" пакет в brew и весь аппрув там - это просто формальность.
Да, вы правы, посыпаю лысую голову пеплом. Именно
dist-upgradeна серверах у меня ничего не ломалСервера тоже разные бывают. До недавнего времени я вообще не мог использовать Ubuntu без PPA (про дебиан не знаю) потому, что там вообще не было OpenZFS, а докер был настолько замшелой версии, что это просто стыдно.
Не так давно ситуация поменялась и OpenZFS появился в официальном репе. А вот с докером беда так и осталась - приходится всё-равно добавлять сторонние PPA, а если так, то о какой стабильности вообще идёт речь.
Если забыть про докер, то в LTS уже изначально идёт люто устаревший софт. Это возможно было нормально когда весь софт компилировался под конкретный дистр с кучей дистрозависимых патчей и поставлялся в бинарниках. Но сейчас, когда огромная часть софта написана на скриптовых языках, жёстко завязана на версию рантайма и зависит от кучи сторонних библиотек, такой подход тупо не работает.
Это в любом случае вынуждает либо подключать PPA для получения более новых версий, либо вообще использовать nvm и npm, venv и rvm. Всё это идёт вразрез с философией дистрибутивов (не только Ubuntu). Более того, сам концепт "стабильных" дистрибутивов в этом месте ломается и никакого решения, кроме контейнеризации, нет.
Да и пусть делают что хотят. По похожим правилам существует Homebrew, например. И ничего - нормально всё. Честно, у меня доверия к нонейм-мейнтейнеру из "команды" арча не больше чем к такому же нонейм-мейнтейнеру случайного пакета из AUR: и там и там может прилететь бяка и и там и там надо так или иначе принимать риск.
Немного отвлечённо, но я жду момента когда можно будет вообще избавиться от мейнтейнеров и исключить их из цепочки разработчик -> пользователь. Это лишнее звено, которое не приносит абсолютно никакой пользу, зато приносит риски.
Я уже зарёкся делать
dist-upgrade. Это всегда тонна багов, которые и вылазят и вылазят и вылазят в будущем после обновления. Да, полагаю, что мне сейчас многие скажут что у них всё работает. Верю (неохотно). Но у меня это нормально не работало ни разу: ни на серваках, где вообще кроме докера считай ничего нет, ни на десктопе. Всегда потом (а то и сразу) вылазят проблемы.Поэтому да - только полная переустановка
Таким образом ключи будут обновляться раз в неделю.На это у меня есть два вопроса:
Почему это не включено по умолчанию?
Зачем мне обновлять ключи чаще, чем я обновляю систему? Если всё настолько ушло далеко вперёд, что обновились даже ключи
archlinux-keyring, то ок - я ССЗБ и буду страдать. Но несколько месяцев между обновлениями - это вообще не срокВ арче есть несколько довольно странных решений, которые почему-то не хотят исправить и сделать более удобным для юзера.
В основном, конечно, претензии к политике по отношению к AUR. Как по мне, нужно:
добавить пакадж-менеджер для AUR в основной репозиторий. Как же замучало каждый раз разбираться со сборкой
yay, которому в очередной раз не нравится версияlibalpm. Сделалpacman -Suyвместоyay -Suyи приветизменить политику по отношению к AUR - это должна быть часть основной инфраструктуры. Сейчас к нему официальное отношение Арча примерно как к сборищу бомжей под мостом, которые норовят тебя ограбить и изнасиловать. Отсюда миллион подтверждений при попытке установки любого пакета через тот
yayили почившийyaourtи другиесобственно, выбрать какой-нибудь PM для AUR и назвать его официальным
Но в с pacman не всё гладко: не понимаю что мешает починить проблему с
archlinux-keyring- всего-то нужно, чтобыpacman -Suy(обновить все пакеты) сначала обновлялarchlinux-keyring, а уже потом всё остальное.Сейчас, если пару месяцев не обновляться, то у части мейнтейнеров пакетов обновятся ключи, а может и появятся новые мейнтейнеры. Далее мы делаем
pacman -Suyи он радостно в каком-то своём порядке начинает качать пакеты, проверять их подписи, а они не совпадают с теми, которые сохранены в системном keyring (он же уже устарел к этому моменту).Что делает pacman? Нет, он не обновляет
archlinux-keyringперед обновлением всего остального, что полностью решило бы проблему, и не советует его обновить тебе самому, и вообще его нигде не упоминает правильное решение. Вместо этого он предлагает абсолютно ошибочное и неработающее решение - вручную добавить ключ мейнтенера в свой keyring. Это никак не помогает, а делает только хуже.Наверное, настоящие арчеводы обновляются каждый день и даже не знают о существовании этой проблемы, но она живёт десятилетия, она постоянно плодит вопросы на форумах и она потратила, наверное, миллионы человекочасов у разных пользователей на своё решение. А ведь исправление заняло бы примерно 5 минут, но...
Давно использую арч на домашнем сервере, но уже принял решение перейти на Ubuntu. Замучали постоянные мелкие проблемы: правда, в основном они касаются докера - то он вообще не работает при установке определённой версии, то перестаёт работать автоматический рестарт контейнеров после ребута (это вообще загадочная проблема, которая попила немало крови, потому что заметить её заранее невозможно), то он перестаёт работать поверх zfs.
В Ubuntu хватает своих проблем, но по совокупности всё же она для меня выигрывает.
Простите, накипело. Просто нужно было выговориться, а тут внезапно кто-то упомянул арч :)
Читал и проверял. И даже обнаружил, что описанный метод всё ещё работает на мегафоне для домена
szfwp.megafon.ru. Он действительно обогощает заголовки запроса и добавляетX-IMSI,X-SGSN,X-IMEISV,X-3GPP-USER-LOCATION-INFOиX-MSISDN- проверяется простой подменойHost.Но ни один из перечисленных в статье доменов так себя не ведёт, по крайней мере если запрашивать корень. О чём я и написал
Вот именно это я и проверял до того как написать свой первый комментарий. Если это и работает, то помимо домена нужен какой-то ещё маркер: специальный путь, или заголовок, или ещё что-то такое. Одного домена тут явно недостаточно
Если он не добавляет эти заголовки в ответ клиенту, то как MAX их получает?
Ваше объяснение не согласуется само с собой:
cleartextTrafficPermittedвключен только для доменов операторов, но не для доменов MAX'а, то есть клиент MAX'а не сможет сделать http:// запрос на свой сервер, а значит, ОПСОС не сможет добавить в него никакие хедеры, а значит сервер MAX напрямую эту информацию от ОПСОСов получить не сможетТо, что внутри инфраструктуры оператора в запросы добавляются служебные хедеры - возможно, но вопрос в том, каким образом эта служебная информацию должна попасть в клиент MAX?
Можете пояснить как это работает?
Я попробовал на Мегафоне, МТС и Билайне - позапрашивал через них соответствующие домены через HTTP и в ответ не получил никаких странных хедеров (единственное что подозрительное нашлось - кука
cookiesession1отidgw.mobileid.mts.ru.Ещё непонятен момент про Header Enrichment: зачем он нужен, если мы всё-равно запрашиваем эндпоинт самого оператора, ведь он в ответ может со стороны сервера без каких-то дополнительных манипуляций добавить в ответ нужные данные.
В общем, буду благодарен, если распишите этот момент более подробно
Зависит от провайдера, но в Москве сейчас MTProxy банится на ТСПУ как протокол у многих. Неважно на какой именно сервер вы подключаетесь - в РФ или нет.
ТСПУ ловит какой-то маркер в рукопожатии и всё соединение после этого идёт лесом.
И да, это касается именно последней версии Телеграма и EE-режима.
Причём, если у вас включен режим с фоллбеком на собственный https-сервер с валидным сертификатом, то обычные https:// запросы из браузера и курла на этот же сервер и на этот же 443 порт проходят без проблем. Палится именно хендшейк mtproxy и палится мгновенно. Это не probe и это не блеклистед IP, просто РКН нашёл какой-то очень качественный маркер в самом трафике и использует его
Напрямую получить состояние сетевых интерфейсов они, конечно, не могут. Зато могут поотправлять запросы на домены из разных зарубежных зон и посмотреть под каким IP вы туда ходите. Если на ya.ru вы зашли из РФ, а на some-metric-tracker.io - из Нидерландов, то тут явно что-то нечисто, а значит, надо ваш нидерландский IP слить в РКН, который радостно заблокирует к нему доступ из РФ.
А если ещё вспомнить про я.метрику, которая есть но почти всех российский сайтах, то становится понятно, что от этого точечно не защититься
Не забывайте про браузер и сайты с я.метрикой (а это процентов 95 от всех русскоязычных сайтов). Придётся ведь и за этим следить.
И простого разделения на
.ru-домены, которые ходят напрямую, и все остальные (ходят через зарубежье) тут недостаточно т.к. сайт (или метрика) в любой момент может запросить трекалку с домена.comи получить ваш "внешний" адресОтличная работа с технической точки зрения. Но с практической гораздо удобнее использовать распознавание внезапно регистрационных номеров: расстояние не так критично, наложения нескольких сигналов нет и точность сильно выше
Я смотрю на всё это и не вижу вообще никакого долгосрочной стратегии. Зато вижу постоянные подмену целей средствами. Детали реализации становятся целями и KPI. А про истинные цели (если они и были) все уже давно забыли и сейчас по факту борются с собственным народом.
На мой взгляд, возникла парадоксальная ситуация: за эти годы с 2022 народ уже привык к внешним и внутренним ограничениям и свыкся с ними. На момент 2024 и начало 2025 года я наблюдал, что обычные люди в массе своей поддерживали власть и были готовы терпеть и дальше. Эту поддержку не уменьшал ни телеграм, ни отсуствие MAXа, ни мобильный интернет. Но тут пришёл некий приказ свыше и власти, руками РКН, начали рубить всё подряд без разбора. Что сделал народ? Начал бороться с РКН. Начал каждый день ждать новой подлянки. Начал обмениваться средствами обхода. Начал задавать вопросы.
И вот прошло 1.5 года активной борьбы РКН со здравым смыслом. И что я вижу сейчас среди обычных людей? Вижу полнейшее отсутствие доверия и поддержки к власти, в т.ч. среди "глубинного" народа. Очень показательна история с МАКСом - любая бабушка уверена, что это какая-то очередная подлянка и скам, который будет за тобой следить.
Самое смешное, что никому извне и изнутри (вспомним все истории с болотными и т.п.) за все эти годы не удалось сделать того, что всего за один год сделала сама власть руками РКН. Я даже затрудняюсь сказать как это назвать - несусветной глупостью или целенаправленным саботажем. Долгое время обычный народ защищал свою лодку от раскачивания, однако сейчас власть просто вынула пробку из дна.
"Планировать" происходит от "план" - ряд предварительно обдуманных действий, мероприятий, объединённых последовательно для достижения цели с возможными сроками выполнения (с) запрещённая вики
Скажите, меня одного корёжит от подачи новостей в таком формате?
Я понимаю, что хороший тон - дать ссылку на источник, но почему нельзя самому взять и перепроверить? Буквально сделать один тап в телефоне и увидеть там то самое сообщение.
И, похоже, все "новости" на хабре от самого хабра оформляются именно в таком стиле - описывается не сама новость, а новость о появлении новости в каком-то стороннем источнике. Будто новостной редактор хабра вообще не субъектен
Может быть, конечно, но я предварительно сходил к ним на сайт, посмотрел как он выглядит и сравнил со скринами приложения - они похожи по цветам, но контролы все разные, да и лейаут другой, более заточенный именно под мобилки.
В общем-то, мне и по тексту показалось, что они всё делали с нуля
Полагаю, вы в том числе и про меня, поэтому считаю нужным ответить: слово "ненавидят" не очень подходит. Это же не какая-то слепая ненависть, а аргументированная позиция людей, которые реально использовали или пытались использовать FreeCAD.
Основная претензия к FreeCAD у всех, кого я знаю - это не то, что он чего-то не умеет или что на нём что-то невозможно сделать. В плане возможностей он как раз вполне хорош и я тоже видел в том же ютубе отличные сложные проекты, сделанные в нём.
Настоящая его проблема - это глючность и падучесть. Пока у вас один скетч - всё хорошо и быстро работает, вытяжка вытягивает, фигуры вращения вращаются. Но с ростом сложности начинают появляться падения, начинаются лаги и глюки. И чем сложнее становится проект, тем чаще он падает и к тем бОльшим последствиям приводят глюки.
Этим можно пользоваться, если нет альтернатив, но это нервы и трата моральных сил на бессмысленную борьбу.
Немного вернусь к изначально теме статьи и поддержу автора в его работе. У меня и самого давно была мысль сделать нечто подобное, но, честно говоря, я не поверил в свои силы и даже не начал. Поэтому немного завидую и желаю всяческих успехов. Реально такого продукта не хватает!