Раз в месяц Microsoft выпускает кумулятивное обновление Windows, которое включают в себя все предыдущие. То есть для приведения системы в актуальное состояние требуется установка единственного апдейта.

Учитывая огромное количество исправлений в Windows, кумулятивное обновление без оптимизации может сильно вырасти в размере, что неприемлемо. Например, его не смогут скачать пользователи с медленным подключением к интернету, а только в США таких 20%. Поэтому уменьшение размера обновлений — приоритетная задача. Теперь для неё нашлось решение.

Если вкратце, то раньше каждое обновление включало в себя прямую дельту изменений системы, а также обратную дельту для приведения системы к базовой RTM, чтобы установить новую прямую дельту через месяц. Однако выяснилось, что обратную дельту можно вычислить в процессе установки обновления. Теперь Microsoft намерена запатентовать этот алгоритм.

Проблема с большим размером обновлений Windows


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

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

Цели


Разработчикам была поставлена задача уменьшить размер обновлений Windows 11 со следующими условиями:

  • Уменьшить размер трафика
  • Не увеличивать время установки
  • Сохранить совместимость со всеми каналами распространения без каких-либо изменений конфигурации, то есть без лишней головной боли для сисадминов

Как выпускаются новые версии Windows


Windows 10 с версии 1809 использовала одновременно прямое и обратное разностное сжатие, где учитываются прямая и обратная разности (дельты) между тремя версиями системы: текущая $V_N$, целевая $V_R$ и базовая исходная $V_0$.



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

Хотя прямая и обратная дельты симметричны по функции, их содержимое в значительной степени отличается. Это значит, что двунаправленная дельта, которая содержит и новые, и старые данные, не намного меньше по размеру, чем старые файлы Patch Storage Files (PSF) в версиях Windows 10 1803 и старше, куда записывались прямые дельты для всех возможных сочетаний $V_N$ и $V_R$, то есть без использования обратных дельт и промежуточной базы $V_0$.

К примеру, если в октябрьском ежемесячном обновлении изменился файл Notepad.exe, то генерировались дельты для изменений файла Notepad.exe с сентября по октябрь, с августа по октябрь, с июля по октябрь, с июня по октябрь, а также с первоначального RTM по октябрь. Таким образом, кумулятивные обновления с каждым месяцем всё увеличивались в размере. Поэтому разработчикам поставили задачу оптимизировать их.

Начиная с Windows 10 1809 механизм изменили — и ввели обратную дельту, благодаря которому размер кумулятивных обновлений всегда оставался практически одинаковым.


Дельта-пары в Windows Update. Чтобы создать целевую ревизию, к базовой версии файла применяется прямая дельта (forward delta). Затем к целевой ревизии применяется обратная дельта (reverse delta), чтобы создать промежуточную базовую версию для следующей прямой дельты через месяц

Чем плоха двунаправленная дельта


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

Генерация данных для обратного обновления


Разработчики Microsoft нашли способ «зафиксировать» на этапе применения дельты все преобразования и исправления — и эффективно перекодировать их из прямой в обратную дельту (n→0), что избавляет от необходимости распространять обратные дельты в паре.

Примечание. Microsoft пишет, что предварительная заявка на патент США № 63/160,284 с описанием этого механизма «Генерация данных для обратного обновления» подана 12 марта 2021 года. К сожалению, найти заявку на сайте патентного ведомства не удалось.




Генерация данных для обратного обновления происходит в процессе применения прямой дельты с инструкциями вставки и удаления данных

Маппинг виртуальных адресов в ассемблере


Архитектурно продвинутые алгоритмы дельта-сжатия, такие как MSDelta от Microsoft, при изменении адреса функции изменяют также виртуальные адреса в ассемблере (маппинг виртуальных адресов). Это важно, поскольку даже небольшие исправления в ассемблерном коде сдвигают адреса последующих функций в бинарной программе. Без ремаппинга виртуальных адресов изменение ассемблерного кода в одной строке может привести к тому, что придётся изменять виртуальные адреса для десятков тысяч вызовов.

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


Пример, как все инструкции call в ассемблере x86 сдвигаются после добавления всего одной инструкции mov по адресу 0x18000097D3 (строка 17)

Обратный маппинг виртуальных адресов в ассемблере


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

Вывод


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

Дополнительная информация



Можно добавить, что все файлы Windows Update подписаны цифровой подписью Microsoft с соответствующим цифровым сертификатом. Наличие у программы сертификата подписи кода гарантирует беспроблемную установку под Windows, потому что Windows Defender SmartScreen учитывает репутацию издателя и не выдаёт предупреждений безопасности при установке программы с сертификатом.

Комментарии (57)


  1. v1000
    07.11.2021 20:59
    +15

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


    1. scruff
      08.11.2021 09:31
      +5

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


  1. 13_beta2
    07.11.2021 22:11
    +13

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


    1. maeris
      07.11.2021 23:29
      +9

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

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

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

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

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


      1. 13_beta2
        08.11.2021 00:40
        +2

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

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

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


        1. Marwin
          08.11.2021 01:25

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

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


          1. DaemonGloom
            08.11.2021 10:55
            +2

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


            1. lamerAlex
              08.11.2021 20:33

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


              1. DaemonGloom
                08.11.2021 20:51

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


        1. Zada
          08.11.2021 04:56

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


          1. khajiit
            08.11.2021 08:49
            +5

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


  1. nicolas2008
    07.11.2021 22:28
    +1

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


    1. maeris
      07.11.2021 23:41
      +4

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

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

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

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

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


      1. nicolas2008
        08.11.2021 02:40

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


      1. trokhymchuk
        08.11.2021 10:09

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

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


        1. dartraiden
          08.11.2021 15:03
          +1

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

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


          1. trokhymchuk
            08.11.2021 17:55

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

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

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

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


      1. dartraiden
        08.11.2021 14:56
        +1

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


  1. alan008
    07.11.2021 22:43
    +1

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


    1. Evengard
      07.11.2021 23:25
      +7

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

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


    1. RC_Cat
      07.11.2021 23:39
      +2

      Вы думаете, Microsoft не платит за трафик с серверов обновлений? :)


      1. DaemonGloom
        08.11.2021 10:57
        +1

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


      1. drWhy
        08.11.2021 11:38

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


    1. dartraiden
      08.11.2021 14:57
      +2

      В статье прямо написано, что у 20 млн американцев (которые у переводчика превратились в 20% почему-то) медленный интернет.


    1. tangro
      16.11.2021 14:05

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


      1. Arioch
        18.11.2021 16:32

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

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

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


        1. tangro
          18.11.2021 16:52

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


  1. gus26
    07.11.2021 23:16

    А что мешает применить эту схему для обновления 10. Или, на нее уже забили и будут всячески вынуждать всех ставить 11...


    1. dwdraugr
      07.11.2021 23:29

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

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


      1. dartraiden
        08.11.2021 14:48
        +2

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

        В оригинале текст в скобках отсутствует, а в Windows 10 применяется иная технология — там в обновлении прилетают прямая и обратная дельты. В 11 обратная дельта вычисляется на устройстве пользователя.


  1. eandr_67
    07.11.2021 23:29
    +1

    Патентовать общеизвестный приём программирования, много лет использующийся, например, в миграциях баз данных? Microsoft решила переквалифицироваться в патентные тролли?


  1. ifap
    07.11.2021 23:50
    +14

    Астрологи предсказали неделю год отвала принтеров после установки обновлений Windows…


    1. yarkovoy
      08.11.2021 05:04

      Лучше не напоминайте...


    1. drWhy
      08.11.2021 11:40

      Бессрочная акция по продвижению безбумажных технологий.
      Apple поддержала, отказавшись от поддержки CUPS.


    1. El_Kraken_Feliz
      08.11.2021 14:29

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

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


  1. ScarferNV
    08.11.2021 12:00

    Все равно, не загонят они меня обратно на Windows. Чем дальше от "окон" тем жизнь счастливее))


  1. Dolios
    08.11.2021 14:14
    +8

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


    1. El_Kraken_Feliz
      08.11.2021 14:34

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

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


    1. Adler_lug
      08.11.2021 14:47

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

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


      1. Dolios
        08.11.2021 15:34
        +3

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


        1. Adler_lug
          08.11.2021 15:39

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

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


          1. Dolios
            08.11.2021 15:47
            +3

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


            1. Adler_lug
              08.11.2021 15:52

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


              1. Dolios
                08.11.2021 16:34
                +5

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


            1. lolikandr
              02.12.2021 07:09

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


              1. khajiit
                02.12.2021 10:55

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


    1. dartraiden
      08.11.2021 15:09
      +2

      Так пусть этот пользователь настроит уже себе систему, в чем проблема? Или у него лапки?


      1. Dolios
        08.11.2021 15:39
        +3

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


    1. oz0ne
      08.11.2021 18:53

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

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


      1. Dolios
        08.11.2021 20:11
        +2

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


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


      1. ScarferNV
        08.11.2021 21:42
        +1

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


  1. NikitaCartes
    08.11.2021 14:47

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

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


    1. dartraiden
      08.11.2021 14:51

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


  1. Metotron0
    09.11.2021 08:15

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

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


  1. imageman
    10.11.2021 11:14
    +1

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


  1. artemlight
    16.11.2021 10:26

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

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


  1. Rikcon
    16.11.2021 11:41
    +2