Жаль, что при всем многообразии кодеков тут почти нет открытых стандартов. Хотя кажется, что тот же Opus со своими низкими задержками и достаточно высоким качеством должен идеально подходить. Или нет?
За подключение к беспроводным сетям отвечает адаптер Killer 1435 с поддержкой Bluetooth 4.2, обоих диапазонов Wi-Fi и даже MU-MIMO 2x2. Со стабильностью коннекта и скоростью передачи данных проблем нет. Это достаточно быстрое и надежное решение, которое не разочарует ни домашних, ни корпоративных пользователей.
Вот с чем не могу согласиться, так это с надёжным решением. Сам мучился с прошлогодним XPS в корпоративной сети, пока не поменял его на Precision того же поколениям с Intel на борту — все проблемы с сетью как рукой сняло.
На том же Dell-сабреддите или форуме самого Dell на них нескончаемый поток жалоб.
Я попробую ещё раз обьяснить: меняет человек себе зеркало в sources.list. Он может это делать любым способом: через ssh, ikvm или любым другим. Насколько высока вероятность, что он только адрес зеркала поменяет, а протокол как был http — так и оставит?
И даже если хозяин зеркала оставил только https, в APT пиннинга, или HSTS. Никто не гарантирует, что http пакеты по пути до зеркала кто-то не перехватывает.
То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?
Защитит ли https от MITM — это тема для отдельной дискуссии. Пока будем считать, что да.
Боюсь, это вы невнимательно читаете. Если владелец репы сделал её доступной только по https никто не мешает кому-то по середине сделать http-proxy со своим содержимым.
А про всякие APT-Security и контрольные суммы — посмотрите CVE-2019-3462.
Статья статьёй, она действительно написана несколько желтовато.
Но самое главное в ней — ссылка на whydoesaptnotusehttps.com за авторством Chris Lamb, откуда все подобные статьи и пошли. Но даже там автор уже написал: надо учитывать, что сайт был сделан до обнародования CVE-2019-3462.
Установка транспорта по-умолчанию ещё ни о чем не говорит. По опыту, количество людей, которые что-то делают со списком зеркал, исчезающе мало.
По-умолчанию в sources.list прописаны http-зеркала. Хостеры вроде DO тоже добавляют свои зеркала по http.
Я буду рад ошибаться, но кажется, что вы нерепрезентативны.
Наушники всем хороших кроме того, что у них на морозе начинает глючить тач и произвольно срабатывать переключения треков/регулировка громкости.
Вроде как Sony даже признали этот баг, но вот починят ли и когда — хз.
Планирование планированию рознь.
То, что происходит на всяческих встречах и стендапах — это совсем не то планирование, которое поможет лично вам быстро и эффективно решать задачи.
Ну так GTD-подход говорит ровно о том же: сначала чётко сформулировать задачи, записать куда-то, а потом выполнять их по порядку согласно заранее сформированному списку.
Тут, конечно, есть довольно интересный вопрос: поиск в Я по слову firefox приносил ссылки на что угодно: на сайт firefox.com, на сайт mozilla-russia.org, на лендинг Яндекса, посвященный скачиванию FF с Я-модулями (кто сказал малваря? Очень, знаете ли, нужные Яндексу модули!), даже на статью про FF на Wikipedia, но — нет ссылок на, собственно, www.mozilla.org/ru/firefox.
Разве кто-то из крупных игроков нынче осуществляет геобалансировку посредством DNS? У этого подхода есть куча проблем и далеко не только те, что вы описали.
В качестве костыля, кстати, когда-то даже придумали EDNS Client Subnet, но количество серверов с его поддержкой мало.
Ну, с приходом TLS 1.3 и 0-RTT Handshake все уже не так плохо. Первое соединение будет долгое, да. А повторные уже будут устанавливаться намного быстрее. Да и в http есть keep-alive.
Тем более, в RFC указан HTTP/2 как минимально рекомендуемый стандарт. То есть, в будущем скорее всего будет и HTTP/3, который сделан поверх UDP/QUIC.
В шторке ещё
Жаль, что при всем многообразии кодеков тут почти нет открытых стандартов. Хотя кажется, что тот же Opus со своими низкими задержками и достаточно высоким качеством должен идеально подходить. Или нет?
Вот с чем не могу согласиться, так это с надёжным решением. Сам мучился с прошлогодним XPS в корпоративной сети, пока не поменял его на Precision того же поколениям с Intel на борту — все проблемы с сетью как рукой сняло.
На том же Dell-сабреддите или форуме самого Dell на них нескончаемый поток жалоб.
4G+ — это такое маркетинговое название LTE-A.
Я попробую ещё раз обьяснить: меняет человек себе зеркало в sources.list. Он может это делать любым способом: через ssh, ikvm или любым другим. Насколько высока вероятность, что он только адрес зеркала поменяет, а протокол как был http — так и оставит?
И даже если хозяин зеркала оставил только https, в APT пиннинга, или HSTS. Никто не гарантирует, что http пакеты по пути до зеркала кто-то не перехватывает.
Защитит ли https от MITM — это тема для отдельной дискуссии. Пока будем считать, что да.
А про всякие APT-Security и контрольные суммы — посмотрите CVE-2019-3462.
Но самое главное в ней — ссылка на whydoesaptnotusehttps.com за авторством Chris Lamb, откуда все подобные статьи и пошли. Но даже там автор уже написал: надо учитывать, что сайт был сделан до обнародования CVE-2019-3462.
По-умолчанию в sources.list прописаны http-зеркала. Хостеры вроде DO тоже добавляют свои зеркала по http.
Я буду рад ошибаться, но кажется, что вы нерепрезентативны.
justi.cz/security/2019/01/22/apt-rce.html
bugs.launchpad.net/ubuntu/%2Bsource/apt/%2Bbug/1812353
Там два вектора атаки — MITM и подмена данных на зеркале. От второго https, конечно, не защитил бы. Но от первого — вполне.
Очень вовремя сегодня опубликовали уязвимость в APT.
Наушники всем хороших кроме того, что у них на морозе начинает глючить тач и произвольно срабатывать переключения треков/регулировка громкости.
Вроде как Sony даже признали этот баг, но вот починят ли и когда — хз.
Планирование планированию рознь.
То, что происходит на всяческих встречах и стендапах — это совсем не то планирование, которое поможет лично вам быстро и эффективно решать задачи.
Ну так GTD-подход говорит ровно о том же: сначала чётко сформулировать задачи, записать куда-то, а потом выполнять их по порядку согласно заранее сформированному списку.
Пост похож на вольное трактование этого подхода.
Но…
В качестве костыля, кстати, когда-то даже придумали EDNS Client Subnet, но количество серверов с его поддержкой мало.
Тем более, в RFC указан HTTP/2 как минимально рекомендуемый стандарт. То есть, в будущем скорее всего будет и HTTP/3, который сделан поверх UDP/QUIC.