On Sun, Mar 22, 2015 at 2:40 AM, Jude Nelson - judecn@???
<devuan.kn.ae5676beef.judecn#gmail.com@???> wrote:
>> The only way not to be forcing anybody is to stick with the least
>> common denominator for everything. That flat out stops progress.
>
> This is simply not true. A key hallmark of good application design is to
> keep the business logic as decoupled as possible from the layers beneath it,
> thereby enabling both freedom of choice for the user and independence from
> the application's needs for the stack's developers. Often, this is achieved
> by means of a "driver" that translates requests from the business logic to
> the underlying layers and back.

There is no application design in that proposal whatsoever. It is only
a proposal to split up a distribution into a set of files with similar
properties and how to use mount to combine those sets again.

> For example, ZFS offers many similar features to btrfs, including
> subvolumes. Moreover, lvm lets you create subvolumes too, and you could
> emulate a subvolume on a vanilla filesystem by keeping each "subvolume" in a
> separate flat file.

So go ahead and use ZFS then. Or go for LVM or even ext4.

Lennart wants to use btrfs since it provides a couple of interesting
properties, and since it is (compared to zfs) widely available on
Linux.

> A well-designed application that lets you
> activate/deactivate different classes of subvolumes for different
> application suites (as Lennart proposed) would define a driver model for
> interfacing with a sufficiently capable filesystem, and would ship with
> driver implementations for interfacing with btrfs subvolumes, ZFS
> subvolumes, lvm volumes, and "emulated" subvolumes. The application suite
> management aspect of the program does not need to be coupled to the
> underlying filesystem implementation; keeping them separate makes it easy to
> add support for new filesystems and volume managers beyond what the original
> developers thought of.

Why on earth would you want to have a driver model? That alone is more
code than the entire functionality of the code you want to plug the
model into!

You are aware that we are talking here about "find a couple of folders
(or subvolumes) following a certain name schema and mount two of
those". That is a script with less than 10 lines of code. Just write
another 10 line script if the original one does not work for you.

> Coupling the application's business logic to lower layers in the stack
> prevents these wonderful properties from manifesting.