Originally Posted by slackerDude
Just learned about "user mode" linux, and openVZ, which sounds a bit more like bedrock, even (same kernel version for all virtual instances), although I guess with bedrock, there is no isolation, and everything is shared, including the process space, etc.
There's also LXC to throw into the mix, and some other technologies. I agree
with you here: in some sense Bedrock Linux is similar to these technologies in
that it lets you run stuff from multiple distros at the same time, with the
notable difference that Bedrock Linux (purposefully) does no isolation. With
Bedrock Linux software from various distros is intended to function as though
the whole thing was meant to work together, rather than as some contained
object isolated from the rest of the system.
Originally Posted by slackerDude
Question for the bedrock guys, and ParadigmComplex in particular: how much work is involved in building it, and once "usable", how much ongoing work needs to be done? Not installation/configuration, but actually backend development? Do you have distribution-specific code that needs to be updated for each distribution you support, or are those more or less transparent? I'm trying to understand the long-term implications of bedrock. Assuming you get to the point of "mostly happy" and it is decently stable, what needs to be done to support another distribution? In other words: can it survive/continue to be useful, even after you, PC, are no longer actively working on it, for whatever reason?
The underlying techniques Bedrock Linux utilizes are generalized. They're
applicable to most "traditional" distros (in contrast to, say, Android). It's
not unheard of to see people in the Bedrock Linux IRC room mention they're
successfully using some distro that I had no idea even existed.
Here's a way to look at it: If two pieces of software have a mutually exclusive
dependency at a given file path, the two files conflict with each other. This
is why most software from one distro fails to "just work" on another. To
resolve this you need both of the dependencies available, and some technique in
place to ensure both pieces of software see their dependencies when they go off
looking for them. Add in the constraint that the two pieces of software can't
be isolated from each other but, rather, have to work together, and you have
the underlying problem Bedrock Linux is solving. Bedrock Linux has a
collection of techniques for ensuring the right files show up at the right
times/places. What technique is applied when/where is configurable. These
techniques are all portable across most Linux kernel builds, and are
relatively low overhead.
For example, you may have multiple "reboot" commands on a Bedrock Linux system
from different distributions. When you run "reboot", you usually
want it to
be the "reboot" command from the same distro that is currently providing your
init. Void's "reboot" works with Void's init, Gentoo's "reboot" works with
Gentoo's init, etc. Bedrock Linux has a configurable system in place which
allows you to ensure when you run a given
command, it comes from a
distro. The following bit of configuration ensures that reboot
always comes from the distro providing init:
$ grep reboot /bedrock/etc/brp.conf
/pin/sbin/reboot = init:/usr/sbin/reboot, init:/sbin/reboot, init:/usr/bin/reboot, init:/bin/reboot
You don't have to configure every single piece of software that specifically;
there's also more generalized rules. I have things configured so that if
something is not a hard dependency (like reboot), the system should prioritize
providing it from a more stable/older distro (like CentOS or Debian) over a
newer one (like Arch). Some people prefer it the other way around.
These techniques are all generalized. They are then configured to be applied to
specific features, where the features are things such as executables,
libraries, desktop icons, application menu items, man pages, etc.
We don't (yet) have techniques for every such feature. For example, if you
install firmware from one distro it won't necessarily "just work" and be
detected by another distro's kernel/udev/mdev. You can work around this by
just installing the same bit of firmware from multiple distros, or copying it
in a number of places. It's not a huge problem, easy to work around, but it
doesn't "just work" quite yet as well as some other Bedrock Linux features.
There is some
distros-specific code/documentation. It is almost entirely
about finding some way to get the distro's files on-disk so they're available
for use. You can use a distro's package manager to get that distro's files,
but you need to get that package manager first. You can
distro in a VM or another partition then copy/mount the files over into Bedrock
Linux, but that's a lot of work, so we've documented instructions (which we
later hope to automate with a utility) to get other distros' files with less
work. That is, naturally, distro specific. Once you have those files on disk,
however, everything goes generalized.
Should Bedrock Linux's development halt, you should be able to continue to use
Bedrock Linux with new distros developed after Bedrock Linux's last release.
However, new features (things like new standards Wayland may bring) may not
"just work" across the various distros without some extra manual work. If
we're lucky, that work may just be configuring the existing techniques to
support them. If not, we need to develop new techniques. Worst case scenario
we have no new technique/configuration and the feature doesn't work across
distros but just with other software from the same distro.
To be clear, such a scenario is a very unlikely hypothetical. I've been
managing Bedrock Linux for a good number of years now, through moves, job
changes, new developers joining the project and others leaving. It's not
likely I'll give it up any time soon. If Bedrock Linux development stops, that
need to find another distro, and as I'm sure you can imagine
there's no other distro out there I like quite as much as Bedrock Linux
Originally Posted by slackerDude
I think we all trust that if Patrick ever decides to hang up his keyboard, we've got others willing to pick up "the slack", as it were. How much "slack" would need to be picked up if you decided to leave. Is it possible to build it in such a way that it just keeps working with new kernels and new distributions, with almost no development work?
Pre-existing features are likely to continue to work. Established standards
like POSIX (which mandates $PATH) and freedesktop.org (which mandates the
.desktop files that populate application menus) are likely to continue for
quite some time. It's those things that Bedrock Linux targets with its
techniques/rules rather than the distros themselves.
Adding support for new features (like the firmware thing I mentioned earlier)
is a bit of a difficult R&D job. If all the current Bedrock Linux developers
hang up their keyboards, I don't see many people who have the skill-set,
time to do so picking up the slack. I'd much prefer to be
wrong here, though. If such people are out there no need to wait for me to
quit, we can use your help now
It shouldn't be hard to continue to document/automate distro-specific bits.
The aforementioned utility for automatically grabbing files from distros should
be easily extended/updated.