> 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.

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. 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.

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

-Jude


On Sat, Mar 21, 2015 at 8:42 PM, <devuan.kn@???> wrote:

> On Sun, Mar 22, 2015 at 1:23 AM, Joerg Reisenweber -
> reisenweber@???
> <devuan.kn.d76efe93d7.reisenweber#web.de@???> wrote:
> > Besides me for one not liking the idea to *get* *forced* to use btrfs
> for /,
>
> The only way not to be forcing anybody is to stick with the least
> common denominator for everything. That flat out stops progress.
>
> > my link rather was referring to statements like >>The classic Linux
> > distribution scheme is frequently not what end users want, either. Many
> users
> > are used to app markets like Android, Windows or iOS/Mac have.<<
>
> As I said: I am not to excited about those apps either. I think
> sandboxing can be a security feature, but not while everything needs
> X11. Great software -- but only when you are safe to assume that
> everybody is nice to each other. We really need to get rid of that
> insecure crap!
>
> > I'm not playing around with concurrent distros either, I'm absolutely
> happy
> > with a single one that works and can get tailored to my needs by _me_
>
> So am I, but I still like to be able to have different versions of my
> distro of choice. I do sometimes break things during an upgrade or
> during the tailoring:-) Maybe you are a better tailor than me, but I
> really enjoy the safety net. And yes, my systems are heavily tailored.
> How else would I be able to implement such a proposal?
>
> But you need to keep your eyes open for new ideas. And sometimes you
> find them in the most unexpected places:-)
>
> Best Regards,
> Karl
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>