> 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, <[email protected]> wrote: > On Sun, Mar 22, 2015 at 1:23 AM, Joerg Reisenweber - > [email protected] > <devuan.kn.d76efe93d7.reisenweber#[email protected]> 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 > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
