From: Sativa@tella.com   
      
   Why LZO was chosen as the new compression method   
      
   by Ian Johnson on 23 December 2020   
   Everyone wants fast applications. Recently, we provided a   
    mechanism to make snap applications launch faster by using the   
    LZO format. We introduced this change because users reported   
    desktop snaps starting more slowly than the same applications   
    distributed via traditional, native Linux packaging formats like   
    Deb or RPM.   
   After a thorough investigation, we pinpointed the compression   
    method as the primary slowdown. Once we introduced the change,   
    some users started wondering why we chose LZO as the new   
    compression method for snaps, given that there are ?better?   
    algorithms available. Here, we want to take you through the   
    journey of understanding why we picked LZO, and what is next for   
    the snap compression story.   
      
   The old way   
      
   Previously, the only supported compression format for snaps was   
    XZ. This decision was borne out of two main determining factors:   
    compatibility and size. One of the primary delivery targets for   
    snaps (in addition to desktop users) is IoT devices, and so for   
    those, we wanted to have the smallest possible size.   
    Additionally, cross-distro support is very important with snaps,   
    and so we also wanted to make sure that the compression format   
    chosen would be compatible with the widest range of kernels. In   
    both cases, the XZ method fit the bill nicely. Additionally, at   
    the time the decision was made, some of the new algorithms such   
    as ZSTD were not even in existence.   
   It?s important to mention a few overarching design goals of snaps   
    before we go much further. The first thing is the choice of   
    squashfs as the packaging mechanism ? instead of distributing   
    individual files as tarballs, etc. We wanted both determinism and   
    ease of deployment whereby all users of a snap get the same   
    files, and those files are not modifiable (by the user). To   
    satisfy both goals, we selected squashfs, which is a compressed   
    filesystem format that is mounted read-only.    
   Orthogonal to that goal was package integrity. It was crucial to   
    have a design where the files that were delivered to users were   
    cryptographically verified, as well. We wanted a system where the   
    bits that make up the .snap file are uploaded to the store by a   
    snap developer, and those same exact bits are delivered to the   
    user without modification. A delta upload/download functionality   
    is used to save on network bandwidth, but that merely   
    reconstructs the original exact bits that the snap developer   
    uploaded to the store. Therefore, we aren?t able to recompress   
    the snap either on the user?s computer or on our servers as that   
    would change the snap files. As such the snap that is uploaded   
    can currently only be uploaded and distributed with a single   
    compression setting.   
      
   Why we needed to switch   
      
   When we started looking into why desktop applications packaged as   
    snaps were slower, we explored multiple hypotheses, and we   
    focused on the difference in startup times between the various   
    packaging formats. For example, here is a graph created at the   
    start of these explorations, demonstrating how many milliseconds   
    it takes to launch a snap application vs the same application   
    packaged natively:   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)