ParadigmComplex

> Tell me this though. Someone who will install Bedrock Linux is most likely a more advanced linux user.

True. We're not targeting the user-friendly crowd for the foreseeable future.

> Would they not just compile from source instead of installing this disto?

Compiling from source does not provide all of the benefits that Bedrock Linux can provide. For example, Bedrock Linux lets you do things like use Gentoo for the vast majority of your system but, if you want a package now and don't want to wait for it to compile, you can just grab it pre-compiled from another distro. Then later compile it if you want and remove the pre-compiled version.

> Should I install a whole different distro just to get pre-packaged software? I think not.

There are people out there who like the flexibility that Bedrock Linux provides, but Bedrock Linux isn't for everyone. If you're 100% satisfied with whatever software stack you're using, I certainly encourage you to stick with it.

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.

If I understand what you're asking: duplicated.

What Bedrock Linux does, from a high-level point of view, is intercept filesystem calls for things that would conflict between two packages and redirect them to something unique per client. So if you have two files that each need mutually exclusive versions of a given library placed in the same path, and they both try to read that path, they'll get different libraries. However, if they try to read something that needs to be the same for interaction (say, a file in /tmp), they'll both see the same file.

The system that picks what is shared between clients and what is kept separate is not very fine-grained; it is broad things like /lib and /usr which are kept separate and unique per client, and things like /home and /tmp that are shared. Or at least that is how it is intended - it is configurable, and in theory you could make it much more fine grained and share libraries and what not. However, that's not recommended.

So yes, as you've likely figured out, Bedrock Linux will eat a fair bit of disk space; you'll likely have multiple different copies of things like glibc on your system. There's no reason a de-dup'ing filesystem couldn't free up space. If you're short on disk space, Bedrock Linux probably isn't the idea distro for you.

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.

> 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)

This is addressed here:

http://bedrocklinux.org/faq.html#why_not_use_bedrock

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.

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.

> The approach of Bedrock Linux is very interesting. It makes use of Linux-specific features like bind mounts and tries to unify several linux distributions into one meta-distribution, which gives the framework for the multi-distribution operations.

Not just "several" - we're going a bit more ambitious and aiming for most if not all.

> They could also use namespaces for a more strict separation of clients, but that's a detail.

We're purposefully avoiding separation of clients. Everything should interact as closely as is possible to how it does normally in other Linux distributions. If a user wants isolation, something like LXC or OpenVZ could be utilized on top of Bedrock Linux just as it could on top of any other distro.

> The idea to move completely to musl is a little bit utopistic, because musl libc is in a very early phase if you want to compile any piece of software of the base system with it. It's mostly C99/C11 and POSIX compilant, but there are several GNU-specific libraries missing, and in a world which uses GNU userland on Linux it's not simple to overcome that limitation.

We want the core to be fairly minimal; it really should be just enough to bootstrap the other clients. The vast majority of the system should, ideally, be acquired from clients, which can use whatever libraries they want. The missing GNU-specific libraries and other limitations of musl aren't hitting anything we need in the core. If we find we need something that can't be provided by musl, we can always switch tracks or double back in a future release.

> The mentioned /etc problem seems to be the same problem as solved by ip-netns(8). Take a look at the source if you need further information, it's based on other bind mounts.

At the moment we've got another plan for remedying the /etc issue which is well underway. I'm using an early version of it right now with surprisingly little trouble. A very deep investigation of possibles uses for namespaces/cgroups is planned for the future.

> But I don't think Bedrock Linux is the next-generation approach for Linux distributions, or rather software distributions in general, though they don't claim that. ... But I think, as you should noticed, that Bedrock Linux has a right to exist, but it won't be the next-generation approach.

I'm not really sure what you mean by that. I'm not really sure how "generations" work with operating systems. It solves a certain set of problems, and has a certain set of limitations.

> "Any one that won't let Bedrock's tools and clients complain" is the answer

Spot on.

> I know nothing about what the author's hinting wrt his future plans, but my impression's that the current release's a fairly light layer of userland tools with only one needing compilation ("bedrock chroot")

Sadly we're adding additional userland tools which will need to be compiled in the next release. However, we're aiming to stick as close to the "fairly light layer of userland tools" description as we can while ensuring the core idea works without issue.

> Kernighan would be proud

I think that is one of the kindest things anyone has ever said about me. Thank you!

It makes efforts to be kernel-version-agnostic; you should be able to use most kernels from most major distros. So yes, if you have a package that requires some special kernel you can probably just use that kernel. However, you will have to reboot to switch kernels like most distros - if you have two packages that each require mutually-exclusive kernel features, you can't use them both at the same time.

For example, the Fedora kernel has special patches for systemtap. You should be able to just boot into the Fedora kernel to utilize systemtap from a fedora userland package, but still get all your other packages from other distros, if you'd like.

Bedrock Linux is relatively kernel-version-agnostic. You can go ahead and use just about any kernel from any major distro and it will most likely just work. So, if you want, you can use an older, proven kernel. My desktop still runs the Debian Squeeze kernel, I think.

Well, it differs from AUR/yaourt in quite a number of ways:

- With AUR, you need someone to maintain the package. With Bedrock Linux, you can use packages aimed at other distros without alteration.

- With Bedrock Linux you don't need to compile anything - you can grab the binary package straight. Or you can compile if you want - with Bedrock Linux, you can use AUR/yaourt/packer/etc from Arch or portage from Gentoo, if you wish.

- With Bedrock Linux, the special stuff is integrated deeply into the system. AUR/yaourt is optional on Arch - on Bedrock, if you ignore the Bedrock-specific subsystems you'll have an extremely minimal and near useless system.

- Bedrock Linux's design results in some neat side-effects for things like robustness against broken packages/clients. I completely fubar'd the /lib -> /usr/lib move in my Arch client on Bedrock, and most if not all of my Arch packages broke. However, the core system continued to work, and I could still use packages from other distros. So I installed whatever packages I cared about from Debian Sid for the time being. Then, later, I blew away my Arch client and installed it again fresh with the /lib -> /usr/lib move completed. There really isn't an equivalent with AUR as far as I am aware.

Hi, I'm the founder and lead developer. Don't hesitate to pop into our IRC channel (#bedrock on freenode) if you have any questions or trouble diving into it. Do keep in mind it is still alpha and has some rough edges (most notably the installation procedure, which is about as manual as you can get), but we're working on resolving such things in future releases.

Hi, I'm the founder and lead developer. Don't hesitate to pop into our IRC channel (#bedrock on freenode) if you have any questions or trouble diving into it. Do keep in mind it is still alpha and has some rough edges (most notably the installation procedure, which is about as manual as you can get), but we're working on resolving such things in future releases.

(I'm the founder and lead dev)

I've not tried that running Gnome 3.X Bedorck Linux, but I don't see why it wouldn't work. One of the people who used to frequent our IRC channel used to use KDE from Arch with the rest of the system from Debian, if I remember correctly, and it worked fine. I use the occasional Gnome application such as Evince without any trouble.

Bedrock Linux has a number of rough edges at the moment which we're working to resolve in future releases, but once those are done I don't see why you couldn't reach cloud nine :)

Hi, I'm the founder and lead dev. We don't have a good document up about how it works because the under-the-hood because it has been changing quite a bit from release to release. However, it is finally starting to stabilize - I plan to have a whitepaper up (and maybe a video presentation) explaining how it works around January with the next release.

A quick explanation: Bedrock utilizes a number of virtual-filesystem manipulation techniques (chroot(), bind-mounts, a number of our own home-grown virtual filesystems such as a specialized union filesystem) to redirect filesystem calls that could potentially conflict. If two packages need different versions of a given library and they both go to read the library with the same path, they'll be transparently redirected to different files. However, Bedrock doesn't "contain" things as one would typically expect with something like chroot(); the packages can all interact like they typically would. Things which need to be the same for different packages to interact are the same. You can, for example, have an RSS feed reader from one distro launch a web browser from another distro to download a PDF which is opened in a PDF reader from yet a third distro, if you'd like. You can have the majority of the system's packages be from a very stable distro like Debian or RHEL but still get cutting-edge packages from something like Arch or Debian Sid, and have portage compile packages from Gentoo, and still get library compatibility with binary blobs aimed at Ubuntu.

This all works - I'm running it now as my main system and have been long before it ever went public - but it still has a lot of rough edges.

Hope that clears things up.

Adding support for signs when diffing would be nifty :)

I threw my own attempt at this on HN a ways back, but it didn't get any traction: https://news.ycombinator.com/item?id=4906343

Mine supports things like multi-key commands and has predictable (if not entirely desirable) undo behavior, but it has issues in its own right. I figure we may both learn a thing or two from each other's attempts.

Vim really does need this feature to get some mindshare back from ST2, and I'd love to see this well-implemented, even if its by someone else.

While quix is quite neat, I don't see how it's really comparable to Bedrock.

I'd like to think this distro is doing something quite unique, sufficiently so to justify its existance in an admitedly large pool of existing distros. The general response from those who took the time to look into what Bedrock Linux actually done has been, over all, quite positive.

That having been said, it's certainly not for everyone, and if you do not think it will serve your interests you're welcome to use something else.

I had hoped to have a video up in time to show off the changes with benchmarks and the like, that will have to be delayed a day or two. Apparently my family members are adamant that they are to spend time with me today.

I rarely post to HN - mostly just read it - but the first page for a search on google for "vim multicursor" has three links to HN were people claim Vim's lack of multicursor support as a primary reason they use another text editor. I figured there would be some interest.