Не надо вводить в заблуждение: прицельно блокировать VLESS отдельно от обычного TLS никто не научился. Если не работает VLESS, то нормально не работает и обычный TLS. На моём VPS не открывается страница с обычного nginx. Я пробовал открывать сайты на соседних с моим VPS IP-адресах и они точно также не работают.
Про обрыв соединений на 16 КБ то же самое: DPI не детектирует прокси, а на определённых диапазонах (обычно CDN) режет любые, в том числе легитимные, соединения на отметке 16 КБ. Это прекрасно видно в браузере или если запросить какой-нибудь файл с такого ресурса curl-ом.
Прошлая так называемая "блокировка VLESS" решалась мультиплексированием: сменой транспорта на gRPC или XHTTP, так как РКН активировал блок на многократные TLS-соединения. В этот раз они усилили блокировки по диапазонам зарубежных хостеров, но избирательной блокировкой VLESS тут точно так же не пахнет.
Гугл привязывает аккаунт к стране по гео-определению IP, при этом номер может быть российским. У меня Antigravity работает на аккаунте, который я регистрировал на российский номер, но при этом никогда не заходил на него с российского IP.
Google Gemini окончательно перестала заводиться через просто VPN. Ты можешь поднять VLESS с самым чистым IP в Нидерландах, но нейронка всё равно выдаст заглушку.
Это не так. У меня работает без дополнительных ухищрений через германский VPS. Причём профиль определяется Гуглом как российский.
Хотите линукс без хлама - велкам ту ручная компиляция, правьте опции сборки под свой конфиг, собирайте, ставьте, в общем, потратьте кучу времени на эту фигню.
Зачем? Этот "хлам" занимает всего несколько сотен мегабайт диска, а в оперативную память без надобности не подгружается. Зато этой небольшой ценой достигается универсальность ядра.
У каждого из этих двух подходов есть свои плюсы и минусы, в обоих случаях приходится идти на определённые компромиссы. Суть в том, что есть выбор. В чём смысл ограничивать себя рамками какой-то одной философии?
Но структура каталогов винды не накладывает никаких требований на хранение бинарей и конфигов, только общие рекомендации, а в линуксе приходится использовать костыли.
Линукс не накладывает жёсткие требование к размещению файлов. При желании вы можете сложить все файлы своей программы в /opt/app_name (так делают, к примеру, google-chrome, virtualbox, onlyoffice, zoom).
Нет, всё-таки разный опыт. В случае Линукса: устанавливаю свежескачанный дистрибутив и видеокарта (AMD) сразу из коробки работает "на полную": родное разрешение монитора, можно заходить в Steam и играть. В случае Винды: после установки с последнего образа - максимально доступное разрешение 1024x768, 3D-ускорение не работает, нужно ждать, когда Винда подтянет драйвер или самому скачивать и ставить руками.
Если сменить кеды на гном... скрытые папки останутся скрытыми. Эта фича изначально как раз появилась в библиотеке GLib, которую используют GNOME, MATE, XFCE, Cinnamon. Потом добавили в KDE. Теперь это стандарт де-факто, работающий во всех популярных графических оболочках.
Как вы тогда предлагаете решить эту дилемму? Большинство пользователей вообще не волнует, какая там философия. Есть потребность — есть решение, это главное.
Radeon RX 9060 XT. Может быть, драйвер и подтянулся бы автоматически через какое-то время, но я не дождался. Ну и по опыту знаю, что драйвера из центра обновлений не всегда актуальные.
На современной винде для того как было сказано "работает нормально из коробки" можно ничего не делать.
Моя видеокарта (AMD) на Линуксе полноценно работает из коробки, а на Винду (11) пришлось скачивать и устанавливать драйвер с сайта производителя. Это просто пример, демонстрирующий, что опыт может быть разным.
Что тут некорректного? И тут, и там пользователи пишут о своих проблемах. А я лишь применил логику комментатора выше: если делать выводы по комментариям, то и Винду можно назвать "отвратительной для десктопа".
Не надо вводить в заблуждение: прицельно блокировать VLESS отдельно от обычного TLS никто не научился. Если не работает VLESS, то нормально не работает и обычный TLS. На моём VPS не открывается страница с обычного nginx. Я пробовал открывать сайты на соседних с моим VPS IP-адресах и они точно также не работают.
Про обрыв соединений на 16 КБ то же самое: DPI не детектирует прокси, а на определённых диапазонах (обычно CDN) режет любые, в том числе легитимные, соединения на отметке 16 КБ. Это прекрасно видно в браузере или если запросить какой-нибудь файл с такого ресурса curl-ом.
Прошлая так называемая "блокировка VLESS" решалась мультиплексированием: сменой транспорта на gRPC или XHTTP, так как РКН активировал блок на многократные TLS-соединения. В этот раз они усилили блокировки по диапазонам зарубежных хостеров, но избирательной блокировкой VLESS тут точно так же не пахнет.
Они начали ещё вчера, 9 февраля.
Впервые за лайки на YouTube, а не вообще впервые.
"What is my location" показывает мой город в России, но Gemini через VPS в Германии всё равно работает.
В инкогнито открывается чат, но в ответ на попытку отправить запрос возвращается ошибка 1060.
Гугл привязывает аккаунт к стране по гео-определению IP, при этом номер может быть российским. У меня Antigravity работает на аккаунте, который я регистрировал на российский номер, но при этом никогда не заходил на него с российского IP.
Это не так. У меня работает без дополнительных ухищрений через германский VPS. Причём профиль определяется Гуглом как российский.
Android работает на ядре Linux.
Зачем? Этот "хлам" занимает всего несколько сотен мегабайт диска, а в оперативную память без надобности не подгружается. Зато этой небольшой ценой достигается универсальность ядра.
У каждого из этих двух подходов есть свои плюсы и минусы, в обоих случаях приходится идти на определённые компромиссы. Суть в том, что есть выбор. В чём смысл ограничивать себя рамками какой-то одной философии?
Линукс не накладывает жёсткие требование к размещению файлов. При желании вы можете сложить все файлы своей программы в /opt/app_name (так делают, к примеру, google-chrome, virtualbox, onlyoffice, zoom).
Нет, всё-таки разный опыт. В случае Линукса: устанавливаю свежескачанный дистрибутив и видеокарта (AMD) сразу из коробки работает "на полную": родное разрешение монитора, можно заходить в Steam и играть. В случае Винды: после установки с последнего образа - максимально доступное разрешение 1024x768, 3D-ускорение не работает, нужно ждать, когда Винда подтянет драйвер или самому скачивать и ставить руками.
Здесь можно взять deb-пакет: http://packages.linuxmint.com/pool/main/m/mintreport/ и сконвертировать его в формат пакетов Арча с помощью debtap: https://www.baeldung.com/linux/arch-install-deb-package
Если сменить кеды на гном... скрытые папки останутся скрытыми. Эта фича изначально как раз появилась в библиотеке GLib, которую используют GNOME, MATE, XFCE, Cinnamon. Потом добавили в KDE. Теперь это стандарт де-факто, работающий во всех популярных графических оболочках.
Со свежим ядром Linux идёт свежий драйвер. А Винда иногда вообще откатывает актуальный драйвер на устаревший из центра обновлений (1, 2).
Как вы тогда предлагаете решить эту дилемму? Большинство пользователей вообще не волнует, какая там философия. Есть потребность — есть решение, это главное.
В случае с AMD драйвер идёт сразу в ядре.
Radeon RX 9060 XT. Может быть, драйвер и подтянулся бы автоматически через какое-то время, но я не дождался. Ну и по опыту знаю, что драйвера из центра обновлений не всегда актуальные.
Моя видеокарта (AMD) на Линуксе полноценно работает из коробки, а на Винду (11) пришлось скачивать и устанавливать драйвер с сайта производителя. Это просто пример, демонстрирующий, что опыт может быть разным.
Что тут некорректного? И тут, и там пользователи пишут о своих проблемах. А я лишь применил логику комментатора выше: если делать выводы по комментариям, то и Винду можно назвать "отвратительной для десктопа".