To satisfy both goals, we selected squashfs, which is a compressed filesystem format that is mounted read-only. 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). The first thing is the choice of squashfs as the packaging mechanism – instead of distributing individual files as tarballs, etc. It’s important to mention a few overarching design goals of snaps before we go much further. Additionally, at the time the decision was made, some of the new algorithms such as ZSTD were not even in existence. In both cases, the XZ method fit the bill nicely. 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. 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. This decision was borne out of two main determining factors: compatibility and size. Previously, the only supported compression format for snaps was XZ. Here, we want to take you through the journey of understanding why we picked LZO, and what is next for the snap compression story.
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. 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.Īfter a thorough investigation, we pinpointed the compression method as the primary slowdown. Recently, we provided a mechanism to make snap applications launch faster by using the LZO format.
Why LZO was chosen as the new compression methodĮveryone wants fast applications.
0 kommentar(er)
