Pull to refresh

Comments 58

Лучше бы они исправили проблему установки самих обновлений.

Лучше бы дали возможность их полностью и легально отключать

Ни у кого не возникает ощущения, что механизм как-то слишком переусложнён?

Возникает, но правильное ли это ощущение? Если посмотреть на то, как гит делает мерж, там тоже всё непросто (может быть, и по легаси причинам: не попробуешь -- не поймёшь). Мои предположения о том, почему получилось так:

  • Обновляют бинарные файлы, у которых тривиальный патч обычно по размеру приближается к размеру самого файла. Кроме того, дифф работает за квадрат времени, и на строковых файлах обычно делается построчно, чтобы N было хотя бы раз в 50 меньше. В бинарниках концов строк нет, есть границы инструкций. Гит, например, даже не стал заморачиваться на этот счёт, и не считает от бинарников диффы совсем. Чтобы это починить, ребята из MS учитывают, что основной дифф создаётся адресами, и заводят маппинги адресов.

  • Обновления могут проходить от любой версии до любой последующей, количество необходимых пакетов обновлений при прямой имплементации зависит от количества версий квадратично. Более простого варианта вернуть здесь линейное количество пакетов, чем разделив пакет на downgrade и upgrade части, я представить не могу.

  • То, что можно патч наложить в обе стороны, видимо, было неочевидно разработчикам до этого (это странно; мне казалось, что аргументы у git diff местами путал хотя бы раз каждый). Что же, зато теперь очевидно.

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

Любопытный обзор, спасибо.

Если вернуться к теме обновления ОС, то морока и с дифами и с базовыми версиями всё равно неочевидна. Мои рассуждения: главная цель — отдать на ЛЮБУЮ предыдущую версию системы АКТУАЛЬНЫЙ объект(ы) текущей ветки. То есть обновление в подавляющем большинстве случаев однонаправленное. Предположим, под объектом чаще всего подразумевается файл. Предположим, что абсолютное большинство файлов в системе не огромные (не больше нескольких мегабайт), тогда архивирования копия файла будет сопоставима по размеру с дифом и будет проще/надёжнее/быстрее для разворачивания. Список файлов, даже в ежемесячном обновлении, обычно в районе десятков-сотен, т.е. zip на пол-образа и близко не ожидается. Тогда прямой архив выглядит более простой альтернативой. Откат конкретного обновления организуется аналогично — банальным бекапом нужных файлов на клиенте.

Интересно, что ВАЖНОГО я упускаю, раз в реальности пришлось городить в т.ч. патчи на exe с правкой релокаций и прочими сложностями. На мой взгляд, такой, более длительный и менее надёжный процесс обновления оправдывается только при цели выйти на минимальный возможный трафик любой ценой.

Откат конкретного обновления организуется аналогично — банальным бекапом нужных файлов на клиенте.

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

Таким образом работают ещё теневые копии в Windows. В любом случае, если нам не нужна возможность отката на любой момент из этих двух лет, а достаточно отката на несколько ключевых точек — никаких сотен гигов там не будет.

теневые копии никаких полных копий файлов не создают

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

Видимо бекапы файлов не попадают под условие "не увеличивать время установки".

На что только в M$ не идут, чтобы не использовать нормальную ФС с нормальными снепшотами и распространять условный refs diff HEAD HEAD^ на базовую систему, а мелкие необязательные патчи засунуть в уже имеющийся оверлей.

Может стоит сфокусироваться на качестве кода вместо изобретения технологий ежедневного обновление дырявой ОС?

Да камон, у них десятки миллионов строк кода и обратная совместимость с 32-битными версиями (т.е. со всем, что было написано за последние 20 лет). В предположении, что код написан так же качественно, как Chrome (это вряд ли, Windows даже не опенсорс), там один баг на 10000 строк кода, т.е. как минимум тысячи, а скорее около сотни тысяч багов, о существовании которых они пока даже не знают.

  1. Не думаю, что даже у MS столько ресурсов найдётся.

  2. Даже если найдётся, профит для бизнеса от починки, например, бага о стрелках на нампаде, начинающих управлять курсором, если paint был открыт на лагающей системе свёрнутым, настолько невелик, что они просто не станут.

  3. И обновлений в результате будет ещё больше.

Если вы о качестве только нового кода, то Microsoft очень даже в тренде.

У меня сложилось впечатление что так было не всегда, а качество начало падать после 2010 года. Баг с нампадом выглядит дико, как будто там костыли на костылях, было что то подобное в Windows 7 и более ранних версиях?

Да камон, у них десятки миллионов строк кода

При чём код ещё очень плохо организован. Они свелосипедили VFSForGit лишь бы как-то можно было разрабатывать винду уже с гитом.

Причем, исходного кода некоторых компонентов уже нет.

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

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

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

Кстати об обратной совместимости. Я успешно напустил в операционной системе от 2021 года приложение, написанное в 2000 году.

Не так много вещей в винде, которые действительно достойны уважения, это одна из них, да.

Кстати об обратной совместимости. Я успешно напустил в операционной системе от 2021 года приложение, написанное в 2000 году.

Самое время в 2021 начать думать про размер апдейтов... Задача актуальная этак в 2005-м, видимо только что добрались, слишком длинный список задач был...

Ну не скажите. Чуть от больших городов отъедешь, и с интернетом уже далеко не так очевидно.

Говорю как тот, кто живёт на не самом стабильном 4G интернете уже 10 месяцев, а альтернативы по сути нет, только в планах и надеждах.

Для этого они ввели функцию скачивания обновлений с соседних компьютеров. :)

Они, кстати, из немногих, не скупящихся отдавать на скоростях выше ста мегабит — видимо опыт массовой раздачи крупных файлов с собственных серверов пошёл впрок.
Жаль только, что большинство устаревших загрузок убирают подчистую.
В статье прямо написано, что у 20 млн американцев (которые у переводчика превратились в 20% почему-то) медленный интернет.

Первые шаги в этом направлении (онлайн-обновление в принципе, сжатие обновлений, дельта-сжатие, дельта-сжатие с учётом особенности архитектуры бинарников) примерно в 2005 и разрабатывались. По крайней мере Vista в 2007 это всё уже имела. Обратную дельту придумали позже. А сейчас вот придумали её вычисление "на лету". Вы не думайте, что всё это сильно просто. Задумайтесь вот так с ходу над реализацией врукопашную дизассемблирования и патчинга всех вызовов при обновлении части бинарника на другую. Нехилая такая задачка сама по себе. А тут уже вторая итерация усложнения этой идеи.

Задумайтесь вот так с ходу над реализацией врукопашную дизассемблирования и патчинга всех вызовов

7-zip это частично умеет. Во всяком случае по его описанию, PE-файлы разбиваются на, кажется, 4 потока и каждый сжимается отдельно, а при распаковке - обратное слияние.

BCJ Converter for 32-bit x86 executables
BCJ2 Converter for 32-bit x86 executables

Да, но тут ещё кто у кого идею взял. Microsoft сделала это в 2007 для Vista и (частично) ещё в 1996 для CAB-файлов. В 7-zip работа над этим (согласно чейнжлогу) только началась в 2009.

UFO landed and left these words here

В этой статье рассказывается о новой технологии сжатия, которая позволила уменьшить размер кумулятивных обновлений в Windows 11 на 40% (аналогичная система реализована в Windows 10). 

И ссылочка там же.

Нет, это отсебятина переводчика.

В оригинале текст в скобках отсутствует, а в Windows 10 применяется иная технология — там в обновлении прилетают прямая и обратная дельты. В 11 обратная дельта вычисляется на устройстве пользователя.
Патентовать общеизвестный приём программирования, много лет использующийся, например, в миграциях баз данных? Microsoft решила переквалифицироваться в патентные тролли?
Астрологи предсказали неделю год отвала принтеров после установки обновлений Windows…
Бессрочная акция по продвижению безбумажных технологий.
Apple поддержала, отказавшись от поддержки CUPS.

И тормозов при отправке не печать. Одна из длинного списка "Странных проблем".

У меня, как обладателя раскладок EN, ES, RU ещё постоянная свистопляска с количеством языков - от двух до 4х.

Имхо, самая большая проблема обновлений виндовс в том, что они, внезапно, не дают пользователю работать. Тебе надо выбегать из дома через 5 минут или у тебя собеседование по видеосвязи через те же 5 минут, ты включаешь компьютер и внезапно ее величество винда заявляет тебе, что ты можешь пойти куда подальше, а она сейчас будет обновляться и это нельзя отменить. Имхо, подобное поведение недопустимо. Никогда. Ни при каких обстоятельствах. Только этот плевок в пользователя уже должен стать причиной отказа от такой ОС.

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

Видимо из двух зол было выбрано это, хотя я однажды так случайно гипервизор перезагрузил рабочий, было неприятно

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

А что мешает переключиться в групповых политиках с автоматической установки обновлений на режим уведомлений и самому решать, когда устанавливать обновление?

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

А что мешает производителю софта сделать так, чтобы пользователю было удобно по умолчанию?

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

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

Я уже писал ниже, могу повторить. Мой линух с настройками по умолчанию умудряется ставить все обновления в фоне. Не перезагружается сам никогда. А когда я перезагружаю его сам, он при включении не просит меня погулять, пока он обновления накатывает. Проблема не в перезагрузках. Типичный пользователь вечером выключает компьютер, а утром включает. Нормальный сценарий: ОС в фоне загружает и устанавливает обновления и применяет их быстро при выключении/включении компьютера, не заставляя пользователя ждать минутами и десятками минут. Последний раз когда я наблюдал за орбновляющейся виндой, она, при включении, 20 минут пыталась накатить какое-то кумулятивное обновление, потом у нее что-то не получилось и еще 20 минут она его откатывала. Для того, чтобы сделать сразу так, как я написал, не нужно никакой телепатии, нужно просто немного подумать о пользователе.

Вам не кажется, что Linux и Windows малость разные ОС? Да и принципы работы тоже разные. Применение принципов из одной ОС на другой из разряда натягивания совы на глобус...

Нет, не кажется. Я сейчас про UX. Принципы работы и прочите технические трудности разработчиков пользователю не интересны. "У нас тут архитектура и принципы, мы так не можем", — это отговорка. Система, рассчитанная на неопытного пользователя должна работать так, чтобы по умолчанию не создавать этому пользователю проблем и не заставлять его разбираться в тоннах настроек. Если принципы не позволяют так сделать, значит это плохие принципы и их нужно менять. Давно вы, например, угол опережения зажигания сами регулировали? А ведь тоже были принципы и некоторые саркастично вопрошали: "а почему бы пользователю не отрегулировать угол опережения?"

Вот только если в момент фонового обновления мне понадобилось срочно поставить пакет, то обычный `apt install` не сработает и придётся ждать, как подсказывают 'Monitor ps or /var/run/apt/periodic to find out when Unattended Upgrades finished it's work.'

За последние лет 7 такое происходило на рабочей машине… 1 раз. И достаточно было повторить запрос после чая.

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

Да что вы все пристали к этими обновлениям? Даже без танцев с бубном можно зайти в настройки и включить отложенные обновления и выбрать время (и не будет сюрпризов за 5 минут до видеозвонка). А если немного погуглить то вообще можно отключить автоматическую установку, не так уж это и сложно. Столько лет уже прошло, а на каждом углу винду пинают за это, хотя актуальность проблемы протухла очень давно. Я лично сижу на десятке со времен беты (или превью, не помню что там было до офф релиза), и уже тогда нашел способ выключить автоустановку, а было в разы сложнее.

Всем пользователям не угодишь - кому-то хорошо что не нужно париться, а кого-то бесит. Если поменять политику - ситуация с недовольством просто поменяется наоборот.

У меня такое чувство, что люди читать разучились. Как мне выбрать время: обновляться в фоне, никогда не перезагружаться самостоятельно, никогда не заставлять меня ждать минуты или десятки минут при выключении или включении компьютера? Я думаю, если виндовс будет обновляться именно так, как это делают другие ос, недовольных не будет. Компьютер обычный пользователь выключает и включает каждый день.


https://habr.com/ru/company/globalsign/blog/587714/?reply_to=23682126#comment_23681384

Рядовой пользователь вообще не должен замечать всяких обновлений и не думать о них, и не мешать ему.

Как я понял, эта дельта для сброса на исходную версию создаётся во время установки обновления.

То есть вместо того чтобы её каждый раз отдавать с сервера, она теперь хранится у пользователя на ПК?

Вся разница в том, что раньше вам приходилось её грузить с сервера, а теперь она генерируется локально. Что экономит трафик и время (при медленном интернете).

Почему бы не хранить исходную версию системы где-то рядом и всё? А то нужно применить обратную дельту, применть новую дельту, посчитать новую обратную дельту.

Можно ведь применять дельту к исходному образу, времени чуть ли не в три раза меньше будет уходить, с трафиком тоже всё хорошо станет.

Мне интересно, использует ли кто-то методы, основанные на чем-то вроде LZMA? По идее можно первым заархивировать старый файл, запомнить место (длину) архива, и как solid (без сброса словаря), потом заархивировать новый файл. Пользователю передавать только хвост, т.к. основное тело он может сгенерировать самостоятельно (старый файл у него есть).

Можно же проще сделать - два варианта обновлений, отдельно кумулятивные и отдельно обновления перехода с актуального ежемесячного роллапа на следующий.

Этого должно бы хватить.

Only those users with full accounts are able to leave comments. Log in, please.