5 ms·

I'm the Bedrock Linux founder and lead developer. I'm happy to answer any questions.

by ParadigmComplex 6y ago

MiguelX413 6y ago
How did you get so based?
- ParadigmComplex 6y ago
  Either stubbornness or perseverance, depending on how charitable one is feeling.
  - reitanqild 6y ago
    Whatever it is, thanks! Edit: and don't burn out.
qlk1123 6y ago
You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, and what triggers you do start this project. As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo.
- ParadigmComplex 6y ago
  > You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, Before Bedrock Linux I was mainly a Debian user. I did briefly run Arch Linux before working on Bedrock, but I found the churn bothersome. While I was running Arch, it updated AwesomeWM from 2.X to 3.X, which changed AwesomeWM configuration formats and functionally broke on my system. Arguably, this wasn't a mistake on the part of Arch Linux developers; the expectation is that the user reads about updates before applying them. Had I done this diligence, I could have withheld the AwesomeWM update. However, I didn't feel like I was able to apply this diligence with the expected regularity. Personally, I prefer Debian's pattern of only releasing security updates with any regularity, only making breaking changes every few years which can be applied when I have time to dedicate to understanding and handling them. Bedrock lets me get _most_ of my system from Debian, but still get newer packages from Arch or rare packages from the AUR when the trade-off of new-ness vs churn is worthwhile for me. > and what triggers you do start this project. I didn't actually set out with the goal to combine distros. Rather, initially (circa 2008) I worked on a sandbox technology. My aim was to fluidly transition resources between security contexts, minimizing user friction while maintaining permissions segregation. I realized only afterward that the technology I developed could be used to fluidly combine features from different distros. Once it occurred to me I could do this, I started seeing use cases everywhere, and pivoted direction to what became Bedrock. > As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo. In that case, I fully encourage you to stick with Arch rather than switch to Bedrock.
akvadrako 6y ago
I wish I could run bedrock linux like homebrew or nixpkgs - just as an alternative packaging system independent of my distro. Is this possible ?
- ParadigmComplex 6y ago
  It depends on exactly what you mean. While you may not have intended it to be, this question is more philosophical than technical. Extended conversations I've had on this topic eventually drift toward subjects like the Ship of Theseus [0] and essential vs accidental properties [1]. For the sake of conversation, lets say your preferred distro is Fedora. If you replace Fedora's web browser with one from Arch, are you still running Fedora? What if you replace the kernel with one from another distro? And the init? Are you still running Fedora if you swap out every single file that is unique to Fedora? Bedrock does not currently support being "uninstalled"; it has to be formatted over, like traditional distros. This is for two reasons: (1) I currently have no way of ensuring any one slice of the system is functionally complete such that removing the rest of the system would leave something bootable. (2) I don't want to advertise support for something active Bedrock users do not themselves regularly exercise, and by its very definition active Bedrock users won't uninstall Bedrock. In theory with enough effort Bedrock could be made uninstal-able, but I don't plan on investing effort there. If a user is interested in testing Bedrock out, I recommend using a VM or spare machine. In every other workflow I can think of, Bedrock can functionally mimic being an alternative packaging system on top of whatever it supports. You can get most of your system - including the install process - from some distro, then use Bedrock to get features from other distros in a way that "feels" like it is "on top" of your original distro. Whether it is "on top" is a matter of semantics rather than practice. With the next major release (0.8) I plan on supporting running Bedrock in something akin to a container. This would let users uninstall it and be less ambiguously "on top" of a traditional distro, but come at the expense of not integrating with the host environment. [0] https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus [1] https://plato.stanford.edu/entries/essential-accidental/ https://plato.stanford.edu/entries/essential-accidental/
  - akvadrako 6y ago
unixhero 6y ago
Hi and thanks for reaching out to the community here. As a poweruser. What are the benefits of this best of all worlds approach, and when might I need them? I genuinely am curious and considering trying Bedrock out. I just can't see what workloads I need it for.
- ParadigmComplex 6y ago
  > Hi and thanks for reaching out to the community here. You're welcome :) > As a poweruser. What are the benefits of this best of all worlds approach, and when might I need them? If you run into a situation where: - The distro that best fits your use case is lacking some functionality you desire - Other distros provide that functionality - The alternatives proposed in this HN thread (compiling from source, alien, chroots/containers/etc, third-party package managers) are insufficient. Compiling from source (`./configure && make && sudo make install`) also means manually maintaining the package for things like security updates, which can be tedious; chroots/containers/etc don't integrate with the rest of the system very cleanly; third-party package managers have limited package coverage (compared to the breadth of the repos of the many distros Bedrock supports); etc Bedrock might be a worthwhile solution. Some concrete real-world examples I've personally run into: - I generally prefer "stable" distros like Debian or CentOS, in contrast to the churn cutting-edge rolling-release distros like Arch and Void are built around. However, when I get new hardware, I usually need a newer component from another distro, which I usually get from Arch or Void. When I purchased a new printer, I need a new cupsd; when I purchased an AMD Zen 2 CPU and was interested in temperature data, I needed a new kernel; etc. - Of the major init systems maintained by a notable distro, I prefer Void Linux's runit. However, as previously mentioned, I prefer non-rolling workflows, which limits my interest in Void. Bedrock lets me easily get init related things from Void and get other things from Debian et al. - Some years back I attended a LUG meeting which had lightning talks on X11 window managers. Newly purchased laptop in hand, I volunteered to present compiz. I found - with only minutes until my time slot - that Debian's Xorg stack was too old to work on the new laptop, but Arch's compiz was apparently broken. Had I run either Debian or Arch, I wouldn't have been able to present compiz during my time slot. Since I ran Bedrock, I simply installed Arch's Xorg stack and Debian's compiz. - While developing Bedrock's 0.7.0 release, I found libfuse 3.0 switched from a make-based build system to meson. Debian's meson was too old ("Meson version is 0.37.1 but project requires >= 0.38."), and Arch's meson 0.44 was too new and included a bug [0] that kept it from sufficing for libfuse. Since I was running Bedrock, it was easy for me to find a goldilocks (0.42.1) version from Debian Testing. - For both school and work, I've been required to run software which assumes a RHEL-like environment. These had things like `#!/bin/sh` scripts that use bash-isms, which don't work on distros like Debian that do not symlink /bin/sh to bash. Bedrock easily lets me run this software against CentOS/RHEL while still letting me easily get the rest of the system from other distros. - I have personal patches against some packages, such as mupdf. Gentoo makes maintaining these packages with my patches trivial, as portage dutifully applies them when updating packages. However, I don't have the patience for Gentoo to compile the bulk of my system. [0] https://github.com/mesonbuild/meson/issues/2761 https://github.com/mesonbuild/meson/issues/2761 > I genuinely am curious and considering trying Bedrock out. I just can't see what workloads I need it for. My recommendation is to simply keep Bedrock in the back of your mind as a possible solution to issues you run into going forward. If you end up stumbling upon enough uses cases, consider it. If you don't, you might very well be better off with some other OS. Most distros exist as they do for good reason, and they suffice for most users. Bedrock targets a fairly niche audience. If/when you do try it, I recommend trying it out in a VM or spare machine before using it in production, to make sure it does what you expect it to do.
justaj 6y ago
Thanks for coming on here. What do you think about Nix and Guix way of managing packages and is there a chance of incorporating similar features into Bedrock (like reproducible builds) ?
- ParadigmComplex 6y ago
  > Thanks for coming on here. You're welcome :) > What do you think about Nix and Guix way of managing packages I have not used either in adequate depth to make strong statements about them. That having been said, I find the idea so far as I understand it obviously desirable, and I would love to see more of the Linux ecosystem move in this direction. Where NixOS and GuixSD is the comparatively limited breadth and depth of packages. There was a point some years back where, upon recognizing the size and scope of Bedrock, I considered instead using the time to package what I find missing from NixOS. After serious investigation, I concluded both that this would be more work in total (Bedrock is, fundamentally, about leveraging work done by other distro maintainers so I don't have to do it [0]) and less interesting work (I find rote packaging tedious, but researching challenging problems enjoyable). > is there a chance of incorporating similar features into Bedrock (like reproducible builds) Given the fact a Bedrock system is mostly features from other distros, this would require making those other distros reproducible. Wrestling other distros into playing with each other is difficult enough; getting them to do that _and_ making other distros reproducible is beyond what is feasible with the resources I have at hand. That having been said, I do take steps in that direction where feasible. Bedrock includes a Package Manager Manager utility, pmm, for cross-distro and multi-distro package management workflows. It supports interacting with a configuration file that lists which packages should be installed from which distros. Mine includes this representative but incomplete section: # desktop environment arch:pacman gtk-engines # needed for gtk theme arch:pacman terminus-font arch:yay terminus-font-ttf # aur gentoo:portage x11-misc/dwmstatus gentoo:portage x11-misc/slock gentoo:portage x11-misc/dmenu gentoo:portage x11-wm/dwm debian:apt dunst debian:apt gcalcli For a sense of why I get what from where: - I prefer Debian and its lack of churn by default. - Gentoo makes maintaining things I compile myself very easy. I have patches for the items I am getting from Gentoo, which Gentoo dutifully applies on updates. - My preferred font is Terminus, which is normally a bitmap font and inaccessible to TTF-only programs. Arch's Arch User Repository provides a TTF version. - Bedrock does not make gtk2 engines, which are *.so shared library files, work cross-distro; this needs to be redundantly installed for each distro that provides gtk2 programs. pmm will add or remove packages from the available package managers as needed to match the configuration file. I track this file with git and use it both to reproduce my system upon new Bedrock installs and to synchronize setup across my fleet. However, this is very limited compared to Nix and Guix. It cannot express, for example, the need to lock a given Arch Linux package to a given version, or to setup a third party repository before attempting to install packages from that repository. I am slowly working towards making more and more things reproducible from simple text configuration, but I do not expect to ever get all of the features Bedrock supports from all of the distros Bedrock supports to be as reproducible as something like NixOS or GuixSD. It should probably also be noted that: - I would eventually like Bedrock to interact nicely with NixOS and GuixSD. Ideally, this would allow at least those slices of the system to be reproducible. Users who value reproducibility could then continue to benefit from them where the available, but still have the option to get bits from non-reproducible distros when the trade-off is worthwhile. - As far as I know, Nix and Guix as stand-alone package managers do work on Bedrock just as they do on other distros. The limitation above is for NixOS and GuixSD only. [0] https://bedrocklinux.org/introduction.html#purpose https://bedrocklinux.org/introduction.html#purpose
Filligree 6y ago
What are the main downsides to using Bedrock? I'm an avid NixOS user, and tend to supply PRs every now and then if I run into problems. If I hit a problem in Bedrock, can I easily do the same?
- ParadigmComplex 6y ago
  > What are the main downsides to using Bedrock? I address them in this FAQ entry [0]. In my experience providing support for Bedrock Linux users for over a decade, the most notable downside is the resulting complexity. This is a fundamental result of what Bedrock is trying to do. There is more to learn, more that could go wrong, and more to wrestle with if something does go wrong. It's perfectly manageable for adequately experienced Linux users, but not necessarily for everyone. > I'm an avid NixOS user, and tend to supply PRs every now and then if I run into problems. If I hit a problem in Bedrock, can I easily do the same? I see two ways to interpret this question: If you are asking whether Bedrock is open to PRs, it certainly is. Bedrock is a _lot_ of work, and I'm always grateful for assistance. Historically, the PRs I've shot down have primarily either been attempts to pull the project in another direction, or ones which break existing functionality. Those which broaden the list of features [1] or distros [2] Bedrock supports, if clean enough, are usually accepted. If you are asking whether Bedrock plays nicely with NixOS, sadly it does not currently do so [2]. I know at least one blocker for Bedrock with NixOS that I plan to resolve in the next major Bedrock release (0.8.0). However, I expect there to be many more. Once I have completed more pressing tasks - sadly, likely years from now - I plan to deep dive into how NixOS works with the aim of getting Bedrock to play more nicely with it. If any of the many apparently large number of NixOS users here find this problem space interesting and would like to work on it before I get to it, I would be delighted. [0] https://bedrocklinux.org/faq.html#why-not-use-bedrock https://bedrocklinux.org/faq.html#why-not-use-bedrock [1] https://bedrocklinux.org/0.7/feature-compatibility.html https://bedrocklinux.org/0.7/feature-compatibility.html [2] https://bedrocklinux.org/0.7/distro-compatibility.html https://bedrocklinux.org/0.7/distro-compatibility.html

I'm the Bedrock Linux founder and lead developer. I'm happy to answer any questions.

MiguelX413 6y ago

How did you get so based?

ParadigmComplex 6y ago
Either stubbornness or perseverance, depending on how charitable one is feeling.
- reitanqild 6y ago
  Whatever it is, thanks! Edit: and don't burn out.

qlk1123 6y ago

You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, and what triggers you do start this project. As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo.

ParadigmComplex 6y ago
> You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, Before Bedrock Linux I was mainly a Debian user. I did briefly run Arch Linux before working on Bedrock, but I found the churn bothersome. While I was running Arch, it updated AwesomeWM from 2.X to 3.X, which changed AwesomeWM configuration formats and functionally broke on my system. Arguably, this wasn't a mistake on the part of Arch Linux developers; the expectation is that the user reads about updates before applying them. Had I done this diligence, I could have withheld the AwesomeWM update. However, I didn't feel like I was able to apply this diligence with the expected regularity. Personally, I prefer Debian's pattern of only releasing security updates with any regularity, only making breaking changes every few years which can be applied when I have time to dedicate to understanding and handling them. Bedrock lets me get _most_ of my system from Debian, but still get newer packages from Arch or rare packages from the AUR when the trade-off of new-ness vs churn is worthwhile for me. > and what triggers you do start this project. I didn't actually set out with the goal to combine distros. Rather, initially (circa 2008) I worked on a sandbox technology. My aim was to fluidly transition resources between security contexts, minimizing user friction while maintaining permissions segregation. I realized only afterward that the technology I developed could be used to fluidly combine features from different distros. Once it occurred to me I could do this, I started seeing use cases everywhere, and pivoted direction to what became Bedrock. > As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo. In that case, I fully encourage you to stick with Arch rather than switch to Bedrock.

akvadrako 6y ago

I wish I could run bedrock linux like homebrew or nixpkgs - just as an alternative packaging system independent of my distro. Is this possible ?

ParadigmComplex 6y ago
It depends on exactly what you mean. While you may not have intended it to be, this question is more philosophical than technical. Extended conversations I've had on this topic eventually drift toward subjects like the Ship of Theseus [0] and essential vs accidental properties [1]. For the sake of conversation, lets say your preferred distro is Fedora. If you replace Fedora's web browser with one from Arch, are you still running Fedora? What if you replace the kernel with one from another distro? And the init? Are you still running Fedora if you swap out every single file that is unique to Fedora? Bedrock does not currently support being "uninstalled"; it has to be formatted over, like traditional distros. This is for two reasons: (1) I currently have no way of ensuring any one slice of the system is functionally complete such that removing the rest of the system would leave something bootable. (2) I don't want to advertise support for something active Bedrock users do not themselves regularly exercise, and by its very definition active Bedrock users won't uninstall Bedrock. In theory with enough effort Bedrock could be made uninstal-able, but I don't plan on investing effort there. If a user is interested in testing Bedrock out, I recommend using a VM or spare machine. In every other workflow I can think of, Bedrock can functionally mimic being an alternative packaging system on top of whatever it supports. You can get most of your system - including the install process - from some distro, then use Bedrock to get features from other distros in a way that "feels" like it is "on top" of your original distro. Whether it is "on top" is a matter of semantics rather than practice. With the next major release (0.8) I plan on supporting running Bedrock in something akin to a container. This would let users uninstall it and be less ambiguously "on top" of a traditional distro, but come at the expense of not integrating with the host environment. [0] https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus [1] https://plato.stanford.edu/entries/essential-accidental/ https://plato.stanford.edu/entries/essential-accidental/
- akvadrako 6y ago

unixhero 6y ago

Hi and thanks for reaching out to the community here. As a poweruser. What are the benefits of this best of all worlds approach, and when might I need them? I genuinely am curious and considering trying Bedrock out. I just can't see what workloads I need it for.

ParadigmComplex 6y ago
> Hi and thanks for reaching out to the community here. You're welcome :) > As a poweruser. What are the benefits of this best of all worlds approach, and when might I need them? If you run into a situation where: - The distro that best fits your use case is lacking some functionality you desire - Other distros provide that functionality - The alternatives proposed in this HN thread (compiling from source, alien, chroots/containers/etc, third-party package managers) are insufficient. Compiling from source (`./configure && make && sudo make install`) also means manually maintaining the package for things like security updates, which can be tedious; chroots/containers/etc don't integrate with the rest of the system very cleanly; third-party package managers have limited package coverage (compared to the breadth of the repos of the many distros Bedrock supports); etc Bedrock might be a worthwhile solution. Some concrete real-world examples I've personally run into: - I generally prefer "stable" distros like Debian or CentOS, in contrast to the churn cutting-edge rolling-release distros like Arch and Void are built around. However, when I get new hardware, I usually need a newer component from another distro, which I usually get from Arch or Void. When I purchased a new printer, I need a new cupsd; when I purchased an AMD Zen 2 CPU and was interested in temperature data, I needed a new kernel; etc. - Of the major init systems maintained by a notable distro, I prefer Void Linux's runit. However, as previously mentioned, I prefer non-rolling workflows, which limits my interest in Void. Bedrock lets me easily get init related things from Void and get other things from Debian et al. - Some years back I attended a LUG meeting which had lightning talks on X11 window managers. Newly purchased laptop in hand, I volunteered to present compiz. I found - with only minutes until my time slot - that Debian's Xorg stack was too old to work on the new laptop, but Arch's compiz was apparently broken. Had I run either Debian or Arch, I wouldn't have been able to present compiz during my time slot. Since I ran Bedrock, I simply installed Arch's Xorg stack and Debian's compiz. - While developing Bedrock's 0.7.0 release, I found libfuse 3.0 switched from a make-based build system to meson. Debian's meson was too old ("Meson version is 0.37.1 but project requires >= 0.38."), and Arch's meson 0.44 was too new and included a bug [0] that kept it from sufficing for libfuse. Since I was running Bedrock, it was easy for me to find a goldilocks (0.42.1) version from Debian Testing. - For both school and work, I've been required to run software which assumes a RHEL-like environment. These had things like `#!/bin/sh` scripts that use bash-isms, which don't work on distros like Debian that do not symlink /bin/sh to bash. Bedrock easily lets me run this software against CentOS/RHEL while still letting me easily get the rest of the system from other distros. - I have personal patches against some packages, such as mupdf. Gentoo makes maintaining these packages with my patches trivial, as portage dutifully applies them when updating packages. However, I don't have the patience for Gentoo to compile the bulk of my system. [0] https://github.com/mesonbuild/meson/issues/2761 https://github.com/mesonbuild/meson/issues/2761 > I genuinely am curious and considering trying Bedrock out. I just can't see what workloads I need it for. My recommendation is to simply keep Bedrock in the back of your mind as a possible solution to issues you run into going forward. If you end up stumbling upon enough uses cases, consider it. If you don't, you might very well be better off with some other OS. Most distros exist as they do for good reason, and they suffice for most users. Bedrock targets a fairly niche audience. If/when you do try it, I recommend trying it out in a VM or spare machine before using it in production, to make sure it does what you expect it to do.

justaj 6y ago

Thanks for coming on here. What do you think about Nix and Guix way of managing packages and is there a chance of incorporating similar features into Bedrock (like reproducible builds) ?

ParadigmComplex 6y ago
> Thanks for coming on here. You're welcome :) > What do you think about Nix and Guix way of managing packages I have not used either in adequate depth to make strong statements about them. That having been said, I find the idea so far as I understand it obviously desirable, and I would love to see more of the Linux ecosystem move in this direction. Where NixOS and GuixSD is the comparatively limited breadth and depth of packages. There was a point some years back where, upon recognizing the size and scope of Bedrock, I considered instead using the time to package what I find missing from NixOS. After serious investigation, I concluded both that this would be more work in total (Bedrock is, fundamentally, about leveraging work done by other distro maintainers so I don't have to do it [0]) and less interesting work (I find rote packaging tedious, but researching challenging problems enjoyable). > is there a chance of incorporating similar features into Bedrock (like reproducible builds) Given the fact a Bedrock system is mostly features from other distros, this would require making those other distros reproducible. Wrestling other distros into playing with each other is difficult enough; getting them to do that _and_ making other distros reproducible is beyond what is feasible with the resources I have at hand. That having been said, I do take steps in that direction where feasible. Bedrock includes a Package Manager Manager utility, pmm, for cross-distro and multi-distro package management workflows. It supports interacting with a configuration file that lists which packages should be installed from which distros. Mine includes this representative but incomplete section: # desktop environment arch:pacman gtk-engines # needed for gtk theme arch:pacman terminus-font arch:yay terminus-font-ttf # aur gentoo:portage x11-misc/dwmstatus gentoo:portage x11-misc/slock gentoo:portage x11-misc/dmenu gentoo:portage x11-wm/dwm debian:apt dunst debian:apt gcalcli For a sense of why I get what from where: - I prefer Debian and its lack of churn by default. - Gentoo makes maintaining things I compile myself very easy. I have patches for the items I am getting from Gentoo, which Gentoo dutifully applies on updates. - My preferred font is Terminus, which is normally a bitmap font and inaccessible to TTF-only programs. Arch's Arch User Repository provides a TTF version. - Bedrock does not make gtk2 engines, which are *.so shared library files, work cross-distro; this needs to be redundantly installed for each distro that provides gtk2 programs. pmm will add or remove packages from the available package managers as needed to match the configuration file. I track this file with git and use it both to reproduce my system upon new Bedrock installs and to synchronize setup across my fleet. However, this is very limited compared to Nix and Guix. It cannot express, for example, the need to lock a given Arch Linux package to a given version, or to setup a third party repository before attempting to install packages from that repository. I am slowly working towards making more and more things reproducible from simple text configuration, but I do not expect to ever get all of the features Bedrock supports from all of the distros Bedrock supports to be as reproducible as something like NixOS or GuixSD. It should probably also be noted that: - I would eventually like Bedrock to interact nicely with NixOS and GuixSD. Ideally, this would allow at least those slices of the system to be reproducible. Users who value reproducibility could then continue to benefit from them where the available, but still have the option to get bits from non-reproducible distros when the trade-off is worthwhile. - As far as I know, Nix and Guix as stand-alone package managers do work on Bedrock just as they do on other distros. The limitation above is for NixOS and GuixSD only. [0] https://bedrocklinux.org/introduction.html#purpose https://bedrocklinux.org/introduction.html#purpose

Filligree 6y ago

What are the main downsides to using Bedrock? I'm an avid NixOS user, and tend to supply PRs every now and then if I run into problems. If I hit a problem in Bedrock, can I easily do the same?

ParadigmComplex 6y ago
> What are the main downsides to using Bedrock? I address them in this FAQ entry [0]. In my experience providing support for Bedrock Linux users for over a decade, the most notable downside is the resulting complexity. This is a fundamental result of what Bedrock is trying to do. There is more to learn, more that could go wrong, and more to wrestle with if something does go wrong. It's perfectly manageable for adequately experienced Linux users, but not necessarily for everyone. > I'm an avid NixOS user, and tend to supply PRs every now and then if I run into problems. If I hit a problem in Bedrock, can I easily do the same? I see two ways to interpret this question: If you are asking whether Bedrock is open to PRs, it certainly is. Bedrock is a _lot_ of work, and I'm always grateful for assistance. Historically, the PRs I've shot down have primarily either been attempts to pull the project in another direction, or ones which break existing functionality. Those which broaden the list of features [1] or distros [2] Bedrock supports, if clean enough, are usually accepted. If you are asking whether Bedrock plays nicely with NixOS, sadly it does not currently do so [2]. I know at least one blocker for Bedrock with NixOS that I plan to resolve in the next major Bedrock release (0.8.0). However, I expect there to be many more. Once I have completed more pressing tasks - sadly, likely years from now - I plan to deep dive into how NixOS works with the aim of getting Bedrock to play more nicely with it. If any of the many apparently large number of NixOS users here find this problem space interesting and would like to work on it before I get to it, I would be delighted. [0] https://bedrocklinux.org/faq.html#why-not-use-bedrock https://bedrocklinux.org/faq.html#why-not-use-bedrock [1] https://bedrocklinux.org/0.7/feature-compatibility.html https://bedrocklinux.org/0.7/feature-compatibility.html [2] https://bedrocklinux.org/0.7/distro-compatibility.html https://bedrocklinux.org/0.7/distro-compatibility.html