Google важно охватить актуальные ОС и железо. Я не вижу причин, зачем Google заморачиваться с поддержкой экзотических дистрибутивов Linux на экзотическом железе. Если это действительно кому-то нужно, они сами найдут ресурсы и время, чтобы собрать свежий Clang и другие зависимости, необходимые для сборки свежего Chromium.
Clang развивается в том числе и Google в том числе и для нужд разработки Chromium. Логично, что Chromium свободно использует желаемые новые возможности из С++20, и это задокументировано. Скорее наоборот, если кто-то напишет код в стиле C++98, то его завернут на ревью, если то же самое можно написать проще и лучше с фишками из C++20. Зачем писать заведомо устаревший код, если речь не идёт про разработку для устаревших систем?
Не нужно во всём видеть злой умысел MS. Visual C++ из самой последней Visual Studio 2022 пока ещё полностью поддерживает сборку программ совместимых с Windows 7, нет никаких ограничений. Qt и Boost не поддерживают Windows 7 только потому, что их авторы больше не видят смысла тратить время на её поддержку.
В случае с бесплатным обновлением Windows 7 на Windows 10 на самом деле сразу было заявлено, что акция временная. В случае же с бесплатным обновлением до Windows 11 никаких временных ограничений не указано.
Почему отдельная? Qt использует тот же самый WinAPI, который в целом кажется что тот же, но на самом деле изменений то тут то там полно, много новых полезных функций, которые хочется использовать в новом коде. А сохранение поддержки Windows 7 — это постоянная трата лишнего времени на тестирование и реализацию фоллбэков для недостающих функций.
А почему они отказываются? Что в Firefox 116 принципиально поменялось по сравнению со 115, что он стал несовместим с Windows 7? 99%, что это искусственное ограничение.
Причины те же. До этого разработчики регулярно тратили то тут то там время на поддержку Windows 7. В какой-то момент на их просьбу перестать это делать менеджмент дал добро, и они с облегчением скинули с себя этот груз. Да-да, это не злой менеджмент внезапно сказал разрабам «Срочно удаляем поддержку Windows 7. Выполнять!», на что разрабы скрепя сердце пошли удалять фрагменты любимого кода. На самом деле, разрабы 3 года ждали решения от менеджмента.
А все остальное — прогресс ради прогресса. Ввели новые API — для чего? Старые же работали...
С таким подходом можно было оставаться на Windows XP и IE6 с Macromedia Flash на пару. Старые API тоже работали и в принципе можно было сделать почти всё то же самое что и сейчас. Пускай с костылями, но можно же, так? Помните костылик для поддержки прозрачности в PNG, который работал почти везде? Ну и что, что он не работал с PNG в фоне, можно же было выкрутиться. Ну и что, что PNG8 с альфа-каналом всё равно не поддерживался, можно было же выкрутиться с PNG без палитры. Так что же, полноценная поддержка PNG не нужна? Ведь это почти то же самое, что и было до этого. Зато с костыликами пользователям не придётся пройти через муки обновления до IE7.
Вот и получается, что вместо исправления косяков старых API придумывают новые. :-(
Так проблемы старых функций тоже регулярно исправляются, они дорабатываются, появляются новые флаги и т.д. Например, стандартный контрол многострочного ввода в Windows 10 научился понимать не только \r\n, но и просто \n. Одновременно с этим стандартный блокнот научился показывать нормально текстовые файлы с такими переводами строк. Эта проблема так долго докучала людей, что об этом изменении даже в новостях писали.
Только проблемы несовместимости в таких случаях, когда используется какой-то новый флаг старого API, гораздо сложнее заметить. Программа запустится и будет работать, но Windows 7 будет игнорировать незнакомый ей флаг, и вроде внешне всё работает, но что-то где-то как-то странно глючит, и без полного тестирования всех возможных юзкейзов такие проблемы сложно отловить. А когда Windows 7 уже не используется при разработке, такие незаметные с первого взгляда баги будут неизбежно попадать в релиз, что неприемлемо.
Кстати, вот прямо вчера в MS STL Discord разработчики MSVC обсуждали отказ от поддержки Windows 7-8.1. Из обсуждения очевидно, что они ждут, когда уже наконец смогут дропнуть поддержку Windows 7-8.1 в рантайме. Ждут, когда менеджмент разрешит сделать новый бинарно-несовместимый рантайм, где уже не будет необходимости поддерживать устаревшие ОС, и где можно будет наконец решить некоторые накопившиеся за 10 лет проблемы (рантаймы VS2015-VS2022 бинарно совместимы по решению менеджмента, из-за чего у разрабов MS STL несколько связаны руки).
IE6, кстати, для своего времени был достаточно прорывным. Просто он задержался слишком надолго (IE7 вышел лишь через 5 лет и был относительно небольшим обновлением), и многие уже доступные в нём вещи позднее в стандарты попали в другом виде.
GUI тоже сильно изменился, и речь не только про новые модные WinUI. В целом очень много изменений касательно поддержки дисплеев с высокой плотностью пикселей, например.
Я почти не занимаюсь UI, но могу вам привести такой пример: Qt6 требует Windows 10 (1809 и новее). Почти наверняка у разработчиков Qt соображения были такие же — слишком много возни ради устаревшей версии ОС.
Qt5 работает на Windows 7, но у него бывают проблемы с HiDPI. Если программа на нём была запущена на мониторе с высокой плотностью пикселей, а потом оказалась на мониторе со стандартной плотностью, окно становится гигантским (и наоборот). Меня эта проблема беспокоит в Telegram Desktop. Он не может перерисовать себя нормально, когда я ноут с HiDPI дисплеем подключаю к внешнему монитору с обычным дисплеем. Как я понял, проблема в Qt5, и она решена в Qt6, но Qt6 требует Windows 10. То есть, по идее, когда Telegram полностью мигрирует на Qt6, проблема у пользователей современных версий Windows решится, но не останется поддержки Windows 7.
Софт, что опирается на Qt, потихонечку перебирается на Qt6. Недавно вот qBittorrent перешёл на новую версию фреймворка (и соответственно избавился от поддержки Windows 7).
Но вообще, для широких масс обязательно нужно обновляться на что угодно просто из-за того, что на Windows 7 скоро не останется ни одного поддерживаемого браузера. Chrome уже почти год как не поддерживает Windows 7, Firefox для Windows 7 остановился на версии 115 ESR, в котором обещают латать дыры до сентября 2024. На Windows 7 можно оставаться только вы не собираетесь из неё подключаться в интернет, а планируете, например, играть в какие-то старые игры или использовать какие-то старые программы.
Сама Microsoft пока что поддерживает сборку под Windows 7 в самой свежей VS2022, но так как софт массово отказывается от поддержки этой устаревшей ОС, не удивлюсь, если в условной VS2025 свежий рантайм также будет требовать не менее Windows 10. И это опять же будет не потому что разработчики в Microsoft такие злые, а просто потому что у них хватает других забот, кроме как заботиться о совместимости с неподдерживаемой и выходящей из употребления версией ОС.
Ну за 10+ лет со времён «семёрки» действительно многое изменилось, даже для обычных не низкоуровневых приложений.
Например, если вы просто хотите сделать обычное консольное приложение в 2023 году, и вас не интересует что там в ядре: поддержку esc-последовательностей для раскраски текста и родную поддержку UTF-8 завезли только в Windows 10+, и это сильно помогает писать кроссплатформенный код.
Некоторые из новых API вообще без страшных костылей не заменить в старых версиях ОС (например, псевдоконсоли, что позволяют встраивать консольку в ваше приложение).
Да, можно выкручиваться без этого, но зачем, если старыми ОС почти никто уже и не пользуется? Это как страдать без современных технологий ради поддержки давно забытого производителем IE6.
У нас не простое GUI-приложение, в котором все проблемы решаются авторами библиотек, на которые приложение полагается. У нас низкоуровневая разработка, мы работаем в основном на уровне ядра или близко к нему, GUI почти нет.
Пишу как любитель Windows XP (на которой я сидел до 2014) и Windows 7 (которая была основной на домашнем компьютере до 2022).
В нашем продукте тоже дропнули поддержку Windows 7 пару месяцев назад, и я лично потратил день на выпиливание всех связанных с ней костылей. Но причина не в том, что Microsoft прекратила поддержку (хотя это конечно развязывает нам руки), а в том, что на поддержку Windows 7 регулярно уходило время, при этом на ней сидит меньше 1% пользователей, так что реальной бизнес-необходимости поддерживать её не было уже давно.
Просто всё оставить как есть не получилось бы, поддержка Windows 7 не получалась сама по себе магическим образом, на это регулярно уходило время. Разработка ведётся на Windows 10-11, соответственно эти версии тестируются прямо во время разработки. Мы выпускаем новые версии нашего ПО каждый месяц. И каждый месяц перед релизом я проверял, а всё ли работает на Windows 7. И практически каждый раз выяснялось, что что-то серьёзно поломалось, и мне приходилось тратить время на починку.
И вот когда при приближении очередного релиза в очередной раз что-то сломалось на Windows 7, я предложил отказаться от поддержки устаревших ОС, и команда это единогласно поддержала. Поэтому вместо того, чтобы в очередной раз тратить время на починку, я потратил время на удаление тысяч строк старых костылей для Windows 7. Думаю, без меня поддержку Windows 7 дропнули бы ещё раньше, так как этим больше никто не хотел заниматься.
Ирония в том, что даже ошибку "Для работы программы требуется Windows 10 и новее" тоже умудрились недавно сломать, и я это вот прям вчера чинил. Даже вывод сообщения о том, что Windows 7 не поддерживается, приходится поддерживать на Windows 7 =) Ну то есть, пока мы хотим выводить внятную ошибку на Windows 7, нельзя, например, напрямую импортировать функции, которые появились только в Windows 10. Но со временем и это станет не нужно.
У меня всё ещё есть компьютер с Windows 7, но теперь он больше для ретро-целей. Старой ОС — старые программы и игры =)
Не вижу ссылок ни на ваш Twitter, ни на Youtube. Возможно, вы забыли их добавить в профиль?
Периодически читаю что там энтузиасты накопали по поводу Монтан (кто-то даже собрал коллекцию из более чем 200 вариаций), но до того, чтобы сделать фотку чипов, пока что вроде как ни у кого руки не дошли, не глядя на легендарность этих часов.
Вероятно, там внутри какой-то стандартный чип, так как идентичное управление и индикация были в многих других часах. Может быть вы обращали внимание, что разные дни недели мигают в зависимости от текущего режима, и на 99% Монтан (кроме редкой ранней модели из 80-х) не было подписей, что это вообще значит. Идентичная индикация текущего режима была в японских SEIKO в 70-х, и там что значит это мигание было подписано прямо на часах. Причём та ранняя Монтана, которая всё же подписывает значение этой индикации режима, делает это точь в точь как SEIKO.
Фотки часов
Seiko из 70-х
Клон от американского (и ныне существующего) бренда Armitron
Дальнейшее развитие от Armitron
Версия из ранних 80-х, экран и поведение идентично Armitron выше
Финальный внешний вид, дни недели (сами двухбуквенные названия вместо ранней прямоугольной метки) мигают в разных режимах как и раньше
Может быть, заведёте сообщество в Discord или в Telegram для отслеживания вашего весьма интересного проекта?
Давно хотел предложить кому-нибудь с таким оборудованием сделать снимки чипов самых популярных вариаций часов Монтана. Там было 2 популярных версии по 8 разных мелодий в каждой. Ну и ещё были старые и новые модели, но скорее всего чип там один и тот же, просто размещение элементов на экранчике немного менялось.
Статья несколько устарела. Финальные версии стандартов QUIC и HTTP/3 уже готовы. Для того, чтобы браузер сразу подключался по HTTP/3, можно использовать новую DNS-запись HTTPS, которая заодно сразу направляет пользователя на HTTPS-версию сайта. То есть, браузеру уже не нужно предварительно отправлять обычный HTTP-запрос через TCP, чтобы получить заголовок Alt-Svc.
64 и 32 бита тоже вполне себе надо поддерживать отдельно. Если просто писать системный код под 64 бита, не задумываясь, как оно будет собираться под 32 бита, то магическим образом оно не заработает, за исключением каких-то крохотных проектов. С сокетами же по сути просто установку соединения под IPv6 надо подправить, а в остальном всё то же самое.
Ближайшая аналогия — переход на 64 бита в Windows. После выхода 64-битной версии большая часть софта продолжала быть 32-битным, так как он работает как у пользователей 32-битных, так и 64-битных Windows, и большей части ПО просто не нужны фишки 64-разрядных процессов, а для перехода на 64 бита нужно ещё и приложить усилия. Сейчас ещё надо поискать 32-битную ОС у кого-то, но огромное количество ПО всё ещё 32-битное. Но кому из программ нужно много памяти и производительность — уже давно только 64 бита, так как пользователей устаревших 32-разрядных систем, которые никак не могут в 64 бита, уже почти не осталось.
Неплохо, уже более 20% сайтов доступно по IPv6. При том, что для хостинга сайтов вообще нет разницы, используется ли IPv6 или IPv4. Разница начинается, когда мы хотим использовать какое-нибудь P2P в играх или хотим напрямую общаться с каждой умной лампочкой дома.
Важно как раз именно то, как много конечных пользователей могут использовать IPv6, из-за этого зависит то, может ли софт рассчитывать на доступность этой технологии у пользователя. IPv6 позволяет избавиться от многих костылей, которые приходится городить в мире, где правит IPv4.
Внедрять IPv6 начали относительно недавно, после World IPv6 Launch Day в 2011 году. Вот оттуда нужно и начинать отсчёт. И спустя 12 лет результат заметный: с 0% до 40%.
Google важно охватить актуальные ОС и железо. Я не вижу причин, зачем Google заморачиваться с поддержкой экзотических дистрибутивов Linux на экзотическом железе. Если это действительно кому-то нужно, они сами найдут ресурсы и время, чтобы собрать свежий Clang и другие зависимости, необходимые для сборки свежего Chromium.
Clang развивается в том числе и Google в том числе и для нужд разработки Chromium. Логично, что Chromium свободно использует желаемые новые возможности из С++20, и это задокументировано. Скорее наоборот, если кто-то напишет код в стиле C++98, то его завернут на ревью, если то же самое можно написать проще и лучше с фишками из C++20. Зачем писать заведомо устаревший код, если речь не идёт про разработку для устаревших систем?
Не нужно во всём видеть злой умысел MS. Visual C++ из самой последней Visual Studio 2022 пока ещё полностью поддерживает сборку программ совместимых с Windows 7, нет никаких ограничений. Qt и Boost не поддерживают Windows 7 только потому, что их авторы больше не видят смысла тратить время на её поддержку.
В случае с бесплатным обновлением Windows 7 на Windows 10 на самом деле сразу было заявлено, что акция временная. В случае же с бесплатным обновлением до Windows 11 никаких временных ограничений не указано.
Ну так Windows 11 и есть бесплатное обновление-дополнение для 10. От того что маркетинговое название изменилось суть не поменялась.
Почему отдельная? Qt использует тот же самый WinAPI, который в целом кажется что тот же, но на самом деле изменений то тут то там полно, много новых полезных функций, которые хочется использовать в новом коде. А сохранение поддержки Windows 7 — это постоянная трата лишнего времени на тестирование и реализацию фоллбэков для недостающих функций.
Причины те же. До этого разработчики регулярно тратили то тут то там время на поддержку Windows 7. В какой-то момент на их просьбу перестать это делать менеджмент дал добро, и они с облегчением скинули с себя этот груз. Да-да, это не злой менеджмент внезапно сказал разрабам «Срочно удаляем поддержку Windows 7. Выполнять!», на что разрабы скрепя сердце пошли удалять фрагменты любимого кода. На самом деле, разрабы 3 года ждали решения от менеджмента.
С таким подходом можно было оставаться на Windows XP и IE6 с Macromedia Flash на пару. Старые API тоже работали и в принципе можно было сделать почти всё то же самое что и сейчас. Пускай с костылями, но можно же, так? Помните костылик для поддержки прозрачности в PNG, который работал почти везде? Ну и что, что он не работал с PNG в фоне, можно же было выкрутиться. Ну и что, что PNG8 с альфа-каналом всё равно не поддерживался, можно было же выкрутиться с PNG без палитры. Так что же, полноценная поддержка PNG не нужна? Ведь это почти то же самое, что и было до этого. Зато с костыликами пользователям не придётся пройти через муки обновления до IE7.
Так проблемы старых функций тоже регулярно исправляются, они дорабатываются, появляются новые флаги и т.д. Например, стандартный контрол многострочного ввода в Windows 10 научился понимать не только
\r\n
, но и просто\n
. Одновременно с этим стандартный блокнот научился показывать нормально текстовые файлы с такими переводами строк. Эта проблема так долго докучала людей, что об этом изменении даже в новостях писали.Только проблемы несовместимости в таких случаях, когда используется какой-то новый флаг старого API, гораздо сложнее заметить. Программа запустится и будет работать, но Windows 7 будет игнорировать незнакомый ей флаг, и вроде внешне всё работает, но что-то где-то как-то странно глючит, и без полного тестирования всех возможных юзкейзов такие проблемы сложно отловить. А когда Windows 7 уже не используется при разработке, такие незаметные с первого взгляда баги будут неизбежно попадать в релиз, что неприемлемо.
Кстати, вот прямо вчера в MS STL Discord разработчики MSVC обсуждали отказ от поддержки Windows 7-8.1. Из обсуждения очевидно, что они ждут, когда уже наконец смогут дропнуть поддержку Windows 7-8.1 в рантайме. Ждут, когда менеджмент разрешит сделать новый бинарно-несовместимый рантайм, где уже не будет необходимости поддерживать устаревшие ОС, и где можно будет наконец решить некоторые накопившиеся за 10 лет проблемы (рантаймы VS2015-VS2022 бинарно совместимы по решению менеджмента, из-за чего у разрабов MS STL несколько связаны руки).
IE6, кстати, для своего времени был достаточно прорывным. Просто он задержался слишком надолго (IE7 вышел лишь через 5 лет и был относительно небольшим обновлением), и многие уже доступные в нём вещи позднее в стандарты попали в другом виде.
GUI тоже сильно изменился, и речь не только про новые модные WinUI. В целом очень много изменений касательно поддержки дисплеев с высокой плотностью пикселей, например.
Я почти не занимаюсь UI, но могу вам привести такой пример: Qt6 требует Windows 10 (1809 и новее). Почти наверняка у разработчиков Qt соображения были такие же — слишком много возни ради устаревшей версии ОС.
Qt5 работает на Windows 7, но у него бывают проблемы с HiDPI. Если программа на нём была запущена на мониторе с высокой плотностью пикселей, а потом оказалась на мониторе со стандартной плотностью, окно становится гигантским (и наоборот). Меня эта проблема беспокоит в Telegram Desktop. Он не может перерисовать себя нормально, когда я ноут с HiDPI дисплеем подключаю к внешнему монитору с обычным дисплеем. Как я понял, проблема в Qt5, и она решена в Qt6, но Qt6 требует Windows 10. То есть, по идее, когда Telegram полностью мигрирует на Qt6, проблема у пользователей современных версий Windows решится, но не останется поддержки Windows 7.
Софт, что опирается на Qt, потихонечку перебирается на Qt6. Недавно вот qBittorrent перешёл на новую версию фреймворка (и соответственно избавился от поддержки Windows 7).
Но вообще, для широких масс обязательно нужно обновляться на что угодно просто из-за того, что на Windows 7 скоро не останется ни одного поддерживаемого браузера. Chrome уже почти год как не поддерживает Windows 7, Firefox для Windows 7 остановился на версии 115 ESR, в котором обещают латать дыры до сентября 2024. На Windows 7 можно оставаться только вы не собираетесь из неё подключаться в интернет, а планируете, например, играть в какие-то старые игры или использовать какие-то старые программы.
Сама Microsoft пока что поддерживает сборку под Windows 7 в самой свежей VS2022, но так как софт массово отказывается от поддержки этой устаревшей ОС, не удивлюсь, если в условной VS2025 свежий рантайм также будет требовать не менее Windows 10. И это опять же будет не потому что разработчики в Microsoft такие злые, а просто потому что у них хватает других забот, кроме как заботиться о совместимости с неподдерживаемой и выходящей из употребления версией ОС.
Ну за 10+ лет со времён «семёрки» действительно многое изменилось, даже для обычных не низкоуровневых приложений.
Например, если вы просто хотите сделать обычное консольное приложение в 2023 году, и вас не интересует что там в ядре: поддержку esc-последовательностей для раскраски текста и родную поддержку UTF-8 завезли только в Windows 10+, и это сильно помогает писать кроссплатформенный код.
Некоторые из новых API вообще без страшных костылей не заменить в старых версиях ОС (например, псевдоконсоли, что позволяют встраивать консольку в ваше приложение).
Да, можно выкручиваться без этого, но зачем, если старыми ОС почти никто уже и не пользуется? Это как страдать без современных технологий ради поддержки давно забытого производителем IE6.
У нас не простое GUI-приложение, в котором все проблемы решаются авторами библиотек, на которые приложение полагается. У нас низкоуровневая разработка, мы работаем в основном на уровне ядра или близко к нему, GUI почти нет.
Пишу как любитель Windows XP (на которой я сидел до 2014) и Windows 7 (которая была основной на домашнем компьютере до 2022).
В нашем продукте тоже дропнули поддержку Windows 7 пару месяцев назад, и я лично потратил день на выпиливание всех связанных с ней костылей. Но причина не в том, что Microsoft прекратила поддержку (хотя это конечно развязывает нам руки), а в том, что на поддержку Windows 7 регулярно уходило время, при этом на ней сидит меньше 1% пользователей, так что реальной бизнес-необходимости поддерживать её не было уже давно.
Просто всё оставить как есть не получилось бы, поддержка Windows 7 не получалась сама по себе магическим образом, на это регулярно уходило время. Разработка ведётся на Windows 10-11, соответственно эти версии тестируются прямо во время разработки. Мы выпускаем новые версии нашего ПО каждый месяц. И каждый месяц перед релизом я проверял, а всё ли работает на Windows 7. И практически каждый раз выяснялось, что что-то серьёзно поломалось, и мне приходилось тратить время на починку.
И вот когда при приближении очередного релиза в очередной раз что-то сломалось на Windows 7, я предложил отказаться от поддержки устаревших ОС, и команда это единогласно поддержала. Поэтому вместо того, чтобы в очередной раз тратить время на починку, я потратил время на удаление тысяч строк старых костылей для Windows 7. Думаю, без меня поддержку Windows 7 дропнули бы ещё раньше, так как этим больше никто не хотел заниматься.
Ирония в том, что даже ошибку "Для работы программы требуется Windows 10 и новее" тоже умудрились недавно сломать, и я это вот прям вчера чинил. Даже вывод сообщения о том, что Windows 7 не поддерживается, приходится поддерживать на Windows 7 =) Ну то есть, пока мы хотим выводить внятную ошибку на Windows 7, нельзя, например, напрямую импортировать функции, которые появились только в Windows 10. Но со временем и это станет не нужно.
У меня всё ещё есть компьютер с Windows 7, но теперь он больше для ретро-целей. Старой ОС — старые программы и игры =)
Не вижу ссылок ни на ваш Twitter, ни на Youtube. Возможно, вы забыли их добавить в профиль?
Периодически читаю что там энтузиасты накопали по поводу Монтан (кто-то даже собрал коллекцию из более чем 200 вариаций), но до того, чтобы сделать фотку чипов, пока что вроде как ни у кого руки не дошли, не глядя на легендарность этих часов.
Вероятно, там внутри какой-то стандартный чип, так как идентичное управление и индикация были в многих других часах. Может быть вы обращали внимание, что разные дни недели мигают в зависимости от текущего режима, и на 99% Монтан (кроме редкой ранней модели из 80-х) не было подписей, что это вообще значит. Идентичная индикация текущего режима была в японских SEIKO в 70-х, и там что значит это мигание было подписано прямо на часах. Причём та ранняя Монтана, которая всё же подписывает значение этой индикации режима, делает это точь в точь как SEIKO.
Фотки часов
Может быть, заведёте сообщество в Discord или в Telegram для отслеживания вашего весьма интересного проекта?
Давно хотел предложить кому-нибудь с таким оборудованием сделать снимки чипов самых популярных вариаций часов Монтана. Там было 2 популярных версии по 8 разных мелодий в каждой. Ну и ещё были старые и новые модели, но скорее всего чип там один и тот же, просто размещение элементов на экранчике немного менялось.
Статья несколько устарела. Финальные версии стандартов QUIC и HTTP/3 уже готовы. Для того, чтобы браузер сразу подключался по HTTP/3, можно использовать новую DNS-запись HTTPS, которая заодно сразу направляет пользователя на HTTPS-версию сайта. То есть, браузеру уже не нужно предварительно отправлять обычный HTTP-запрос через TCP, чтобы получить заголовок Alt-Svc.
Важно как раз именно то, как много конечных пользователей могут использовать IPv6, из-за этого зависит то, может ли софт рассчитывать на доступность этой технологии у пользователя. IPv6 позволяет избавиться от многих костылей, которые приходится городить в мире, где правит IPv4.