This strikes me as a terrible hack. Yes, I've run into all of the problems this is trying to solve, but if this is what is necessary to fix them, I rather build my packages from source (or use *BSD and ports/pkgsrc).
One of the requirements on Bedrock Linux is the requirement that it can be developed and maintained by an individual - me. I've gotten plenty of help but I've been firm that in case the help dries up the project never grows out of the scope of what I can do alone. Another requirement is that the project actually get to a usable state - I actually want (and now have) what Bedrock Linux promises; I don't want it to remain some theoretical academic solution. Finally, it should stabilize - I don't want to have to maintain forks of anything, or continuously work against the tide of changes in the rest of the F/OSS world. Given that, I don't think there is a completely aesthetically pleasing way to go about doing what Bedrock Linux aims to do.
There are potentially cleaner approaches, but they require immensely more manpower than I could seriously consider mustering. There are options such as writing and upstreaming new system calls to implement some sort of union-filesystem/chroot() mix, which, based on past attempts to upstream a union filesystem into the kernel, won't happen. Other approach is to altering/packaging every single package I am interested in - including proprietary software - so that they play nicely together. Nix/NixOS is making an admirable attempt here, but they don't have the manpower to package enough things. For now, Nix is, sadly, academic.
Personally, I find that while it isn't the simplest system from a high-level design point of view, Bedrock Linux's approach is by far the most practical solution to the problem I aimed to remedy. And it works, and I'm running it now. It is certainly not for everyone or for every use case. I made it for my own uses, which it serves admirably. Enough people seemed interested that I made it available publicly. You're welcome to continue using whatever software stack you prefer - I don't intend to snag everyone. Or even very many people. I'm happy to be the only one using it. However, I do aim to share if there are others out there interested in it.
I was wondering if this was influenced by Nix. I believe they're really on to something with that system, but it's tremendously tricky to use at this point in time.
Bedrock Linux wasn't influenced by Nix. When I started working on what ended up being Bedrock Linux, I wasn't familiar with Nix. Both projects are going about things in very different manners. Nix's is a lot cleaner, but will take a lot more manpower or time to get to the point where I could use NixOS as my primary system. I agree that they're on to something - I'd love for Nix project to take off.
Bedrock Linux can use either (or both!) portage and paludis just fine. What Bedrock Linux does is at a lower-level below package managers - in theory, it should work with just about every package manager out there. When listing examples of what Bedrock Linux can do I usually list portage as it is better known.
Beat me to it. Nice idea but isn't building from source more effective? Gentoo does this instead of attempting to hide complexity in one-size-fits-all packages. Also...
Fat kernel = huge attack surface.
Funky chroot / path stuff = source of bugs.
Multiple distro-specific APIs = n x sync latencies, n x diskspace, n x attack surface
Size of user community = 1 / n x 0.1337 (contingencies' constant)
> Beat me to it. Nice idea but isn't building from source more effective? Gentoo does this instead of attempting to hide complexity in one-size-fits-all packages.
Oddly enough, the vast majority of Bedrock Linux users, from what I can tell, are ex-Gentoo people. If you've come to the understanding that building everything from source is a viable alternative to what Bedrock Linux is trying to do, you've misunderstood (which could be my fault for not being sufficiently clear). One of the things Bedrock Linux provides is a way to build your system with Gentoo's portage, but still have the option to get something else now from some other distro if you don't have the time or patience to compile it with portage.
> Fat kernel = huge attack surface. Funky chroot / path stuff = source of bugs. Multiple distro-specific APIs = n x sync latencies, n x diskspace, n x attack surface. Size of user community = 1 / n x 0.1337 (contingencies' constant)
Basically, yes, you're correct. If you value such things very highly, Bedrock Linux isn't the distro for you. Maybe hardened Gentoo or Qubes OS would be better suited.
I'd argue Arch improves on this. You can get standard software and anything already packaged elsewhere via pkgbuild, or just use the skeleton git repo pkgbuild to pull source and build it behind the scenes anyway. Best of both worlds - save some electricity and time and have access to all the softwares.
Wasn't meaning to start a distro thread, but yeah I've noticed there's lots of nice docs from arch and the community seems quite large. Haven't tried it myself but understand its build system provides less configurability, so don't think I'd gain from a switch. (I use a lot of Gentoo USE config stuff, particularly on cluster and higher security node deployments to reduce dependencies and overall code bloat, which is one reason I really value Gentoo. Though still not perfect, it's pretty damn good for many of my use cases.)
