Consider distr1 for an image-based rather than package-based system

[probonopd]

https://github.com/distr1/ puts together a whole Linux system using (currently: uncompressed squashfs) images.

I am wondering whether we could use it to

• Put together a Live ISO that would contain essentially a folder of images
• To "remaster" the Live ISO, we would just have to add/remove/exchange some of the images
• At installation time, just copy over that folder of squashfs images, and have a modifyable/updateable system (by putting each FreeBSD pkg into an image)
• Being able to put together .app bundles by just putting the relevant images into the bundle

This would

• Speed up Live ISO generation significantly
• Simplify Live ISO generation
• Speed up CI significantly
• Speed up package management on the installed system
• Still allow us to use something vaguely similar to AppImages/.app bundles for applications

Can it be ported to FreeBSD? (I've been interested in FreeBSD lately because it is much more of a consistent platform than the various incompatible Linux distributions.)

Additional food for thought:

• Can the distr1 approach benefit from ZFS? (For example: If we make .app bundles that contain a bunch of images, could ZFS deduplicate those with less overhead compared to having deduplicate all of the files without images?)

cc @stapelberg (hi @stapelberg. I am the AppImage guy. With hello, I want to make something 10x as good.)

[probonopd]

Blocked by jacobsa/fuse#91

[probonopd]

This could also be the basis for an AppImage/AppDIr-like system but for FreeBSD, taking into account FreeBSD strengths and constraints.

(Basically, think of every pkg being a zfs/squashfs filesystem image, and an AppDir being a directory consisting of one or more pkgs which would all get union-mounted together before and over / from the viewpoint of the application.)

[dch]

dropping this from IRC, https://github.com/seaweedfs/fuse is a working fuse-on-FreeBSD implementation. I can't tell if the go code you're using is a drop-in replacement or not, but at least that one works.

[dch]

wrt zfs and deduplication, TLDR no. The tradeoff is a large RAM lookup table vs incremental loss of disk space. You could look at using aggressive zstd compression on datasets, which might gain you more than gzip/lz4 defaults.

wrt squashfs, I'm guessing you've seen the mdconfig support already in the kernel?

[probonopd]

Thanks @dch.

This is a fork of http://bazil.org/fuse , for performance and to merge all good pull requests.

Would you expect something like https://github.com/distr1 to be easy to switch over from https://github.com/jacobsa/fuse/ or would that likely be a massive undertaking?

[grahamperrin]

#22 (comment)

… aggressive zstd compression on datasets, …

+1 however re: helloSystem/ISO#135 and other issues, there's not yet use of OpenZFS for the live system.