possibility of installing non-invasively over existing system

[brainchild0]

Does the technical design of Bedrock Linux allow for the possibility of evolution toward some variation that would install over an existing operating system without hijacking it?

In such a hypothetical scenario, the layout and function of an existing system would remain the same after a new installation, but it would allow new strata to be variously added and invoked as an auxiliary layer. The documentation provides a good analysis of how the usefulness of containers is often misunderstood, because they enforce a full separation of file system, user configuration, and other basic features of a local site. Even so, containers have the advantage that they but not Bedrock operate without any changes to the essential system.

[paradigm]

Yes. It's scheduled for 0.8.0 which will hopefully be out sometime next year.

I'm reasonably certain most people who think they prefer this haven't fully thought it through, but having a good faith, polite discussion every time it's brought up, patiently helping people work through the process of thinking about this domain, isn't scaling with Bedrock's growing user base and attention. My hope is offering both models with documentation explaining the trade-offs will encourage at least some users to think the situation through a bit more. And, ultimately, Bedrock is about user choice, even if that means choice that doesn't align with my own.

Other distros have already pioneered a "as-a-distro" vs "on-another-distro" dual model, such as NixOS vs Nix and Gentoo vs Gentoo Prefix. The plan is for Bedrock to follow suite. The 0.8 installer will allow users to choose between a "full" Bedrock Linux install, with the full Bedrock Linux feature set but without the ability to reliably uninstall it, and a "hosted" Bedrock Linux install, which runs on top of another distro as an application but has many features disabled to ensure the system does not become reliant on Bedrock.

[brainchild0]

I'm reasonably certain most people who think they prefer this haven't fully thought it through, but having a good faith, polite discussion every time it's brought up, patiently helping people work through the process of thinking about this domain, isn't scaling with Bedrock's growing user base and attention.

Would you mind explaining? For me the central crux of the matter is Not reversible!, in the sense that if the original system may be preserved beneath any overlay, and may be recovered if desired, then users may derive the benefits of the strata with safety and comfort.

[paradigm]

Would you mind explaining?

Usually it's a long back-and-forth where I first need to figure out what the other person is thinking in order to see what they're confused about that I could correct; I can't just explain it outright.

Moreover, I've had this conversation many times and I am burned out on it. Forgive me if I don't have the patience to do so again. I'd rather use the time and energy working on developing the associated technologies.

For me the central crux of the matter is Not reversible!, in the sense that if the original system may be preserved beneath any overlay, and may be recovered if desired, then users may derive the benefits of the strata with safety and comfort.

I don't see the difference between what you're describing here and the general concept of backing things up. Bedrock isn't particularly suited to offering a backup system; there's plenty of establish solutions out there already.

[brainchild0]

Although not wishing to draw you into a discussion you prefer to avoid, I must confess confusion, because it has appeared that you have explained both that a feature is planned and also have rejected it.

Meanwhile, backup is a very different matter from reversibly adding a new layer or component to a system in a way that has no disruptive effect on the existing system. Backup allows an entire system to be restored fully to a previous state. I am trying to discuss the possibility of adding a layer, much any other application or subsystem (e.g. Docker, libvirt, Flatpak, Guix, or as you mentioned, Nix), such that the system and any data artifacts may be removed without affecting the rest of the system, and without reversing changes made to the system since the earlier installation but not related to the subsystem removed.

[paradigm]

I don't wish to try to force you into a discussion you prefer to avoid, but I am confused because it has appeared that you have explained both that a feature is planned as well as having rejected it.

I see where I said a feature was planned. I can't find where I said I was rejecting anything.

Meanwhile, backup is a very different matter from reversibly adding a new layer or component to a system in a way that has no disruptive effect on the existing system. Backup allows an entire system to be restored fully to a previous state. I am trying to discuss the possibility of adding a layer, much any other application or subsystem (e.g. Docker, libvirt, Flatpak), such that the system and any data artifacts may be removed without affecting the rest of the system, and without reversing changes made to the system since the earlier installation but not related to the subsystem removed.

You've been consistently courteous and reasonable throughout every interaction we've had, which I really do appreciate, and I would much rather respond in kind than glibly or curtly. However, given past experience having this same discussion over and over, I lack the time and patience to work through the process again here.

Suffice it to say something vaguely along these lines is planned. My hope is that will act as an adequate contrast to the existing Bedrock model to make my concerns with it more readily evident, or failing that, that it's adequate to meet the desires of those who request it.

[brainchild0]

You may not have directly given a rejection, but you have provided a line of explanation that carried the general appearance of one, as well as I would be able to characterize it, and I am confused about how to integrate such remarks with the fact of the feature being planned.

At any rate, should more information or explanation be posted on the subject, please consider adding a reference to the current discussion.

[paradigm]

You may not have directly given a rejection, but you have provided a line of explanation that carried the general appearance of one, as well as I would be able to characterize it, and I am confused about how to integrate such remarks with the fact of the feature being planned.

Since explaining it directly isn't working, let me try an analogy. Lets say most people are used to cars, and I invented the airplane. Almost everyone who takes interest in the airplane find it surprising at first - it isn't what they expect based on their prior car experience. The majority of these folks respond to this weirdness by actually taking the time to familiarize themselves with airplanes. Maybe it's for them, maybe it's not, but they're open minded enough to try to understand it on its own terms and why it's different from cars. A minority run with their initial model and just assume the airplane is just a bad car.

This minority do things like point out that the airplane catches the air and gets thrown around in strong winds. They claim this is a flaw - Ford cars don't do this, nor do Honda cars, and so neither should this weird "airplane" car.

This minority do things like point out that federal law puts a limit on a car's width. All the major car brands respect this standard. The fact this "airplane" car has these wide wings is against the standard.

After spending over a decade patiently trying to encourage people to actually learn about the airplane before passing judgement or proposing improvements, I've concluded the current approach isn't scaling. I need to find another way to teach people about airplanes, since a select group of people clearly refuse to do things like read documentation or actually try it out.

My current theory is to just offer both an actual airplane, and an airplane with the wings clipped off. My hope is when this minority of folks go to try out an airplane, the fact there's two options will encourage them to stop to consider the choice, which will hopefully include learning why an airplane with wings is an option.

[brainchild0]

Perhaps it would be helpful simply to list some prominent features, use cases, design considerations, and so on, and to explain how they conflict with the suggested scenario. It may be ignorant to suggest that a plane might fly with clipped wings, but it is rather easy to explain, especially if only in a very cursory sense, a reason for the idea being absurd.

I am not necessarily suggesting doing so here, but perhaps as a general approach to the problem you are explaining.

For some, such as myself, asking the questions that may seem to others frivolous, as ones about a wingless airplane, are far from a path of reaching judgments without learning, but instead a path for learning.