
Bedrock Linux - duggieawesome
http://bedrocklinux.org/
======
ineedtosleep
Honestly, at first I wasn't too surprised by this, but as I thought about it
some more, it's actually pretty damned impressive. Boiling it down a bit,
would it be fair to call this a "more universal AUR/yaourt"?

~~~
ParadigmComplex
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.

------
eeadc
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. They could also use namespaces for a more
strict separation of clients, but that's a detail.

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.

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.

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. I'm working on my own Linux distribution since about a year and
it's based completely on a ports tree, as known from FreeBSD, but with a
simpler code base and simpler Makefiles. At the moment, I'm trying to create a
stable commit, which will build without issues in several configurations, but
that's hard work, especially because Linux or rather the Linux userland is
mostly a ghetto™ (you won't get information about much low-level software).

But I think, as you should noticed, that Bedrock Linux has a right to exist,
but it won't be the next-generation approach.

~~~
ParadigmComplex
> 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.

------
chamakits
This is very exciting.

I cannot count the times that I've wanted this "one specific program" which
isn't available in my distro's repo, which also depends on a version of a
library that is also not available in my distro's repo. Will definitely take a
look at this.

Kudos.

------
zidar
"a rock-solid stable base yet still have easy access to cutting-edge packages
..." This sounds really nice in theory and I hope they can pull it of, but I
can't see how that can work.

~~~
hrjet
I guess they mean: system packages which are stable, but apps that are
bleeding-edge.

~~~
zidar
And I still can't see how that would work. Some apps need the latest libraries
latest kernel or something, so without "bleeding edge" system core some apps
won't even run. There are always workarounds to that but those cause more harm
than good.

Still I will keep an eye on Bedrock hoping they come up with something cool.

~~~
ParadigmComplex
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.

~~~
zidar
Thank you for the explanation. It sounds to me that even if I want to use a
package from a stable release like debian, there's another layer possible
bugs. That said, I really like the idea. Wish you guys the best of luck and
I'll be keeping a close eye on the progress.

------
codex
In this distribution, are shared libraries really shared, or duplicated?

~~~
ParadigmComplex
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.

~~~
codex
I would be more concerned with the RAM these libraries consumed. Some may just
use code pages, but others may use large amounts of BSS.

~~~
ParadigmComplex
That's also a very legitimate concern. On systems with limited RAM - or disk
space - one should either limit themselves to a relatively small number of
clients/packages, more likely, prefer another operating system.

------
wesleyac
Very cool, but I'm happy with Arch.

~~~
delluminatus
How do you know if someone uses Arch Linux?

Don't worry... they'll tell you! (BTW I use Arch)

~~~
antocv
This joke has to die.

For the 100 or so readers of this article who may be archlinux users, 1 will
say so and the joke is alive and this reflects badly on the archlinux
community as a whole - who are not elitist schmucks or evangelists for
archlinux. There is those who mention they use ArchLinux, so what, whats the
big deal?

Why not make the same joke for anyone who mentions that they run macosx or
some other apple product?

~~~
chris_wot
So I take it you are an Arch user?

~~~
antocv
You mad bro?

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

~~~
ParadigmComplex
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.

~~~
tel
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.

~~~
ParadigmComplex
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.

------
swinglock
Interesting. Which kernel does it end up using? Could it handle packages which
wants a special kernel or different modules for different kernels?

~~~
rplacd
"Any one that won't let Bedrock's tools and clients complain" is the answer -
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 mostly shell-
scripted userland tools with only one needing compilation ("bedrock chroot");
Kernighan would be proud. (Those who treat the Unix Haters' Handbook as a
source of design maxims would simply conclude a runtime built upon an
introspectable and introcessionable language would obviate the need to marvel
at the engineering involved here. The initial effort involved here, to be
fair, is orders of magnitude less.)

~~~
Tobu
introcessionable? Google doesn't know that word, you get to define it.

~~~
rplacd
Gah - typo - "intercessionable" is the word; I've taken its use from the the
Art of the Metaobject Protocol. (Thanks for the double-checking.) It's a usage
that doesn't bear much relation to its others, but it's fairly easy to define:
if introspection queries internal state, intercession changes it.

------
gsarrica
Tell me this though. Someone who will install Bedrock Linux is most likely a
more advanced linux user. Would they not just compile from source instead of
installing this disto? Should I install a whole different distro just to get
pre-packaged software? I think not.

~~~
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.

~~~
gsarrica
Thanks for responding. Was not trying to rag on the work you have done. It is
very intriguing to see the work you have done, however I am just not sure
about the targeted audience.

------
sdfjkl
I just remembered what else this reminded me of:
[http://en.wikipedia.org/wiki/Universe_%28Unix%29](http://en.wikipedia.org/wiki/Universe_%28Unix%29)

~~~
luckydude
I used Masscomp's version of this, it was sort of neat. They did it (if I
remember correctly, long time ago) with a symlink that contained an
environmental variable.

/usr/lib -> /usr/$UNIVERSE/lib

or something like that.

It was a little disgusting having the kernel grok env vars but it worked quite
well.

------
Zardoz84
Interesting... I will need to try it.

~~~
ParadigmComplex
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.

------
bachback
very nice. what are some of the wider/long-term implications of this?

------
dilipray
it made my day. I'm ready to dive. :)

~~~
ParadigmComplex
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.

------
JSno
how could it be possible since not any relative new version of kernel can be
claimed rock solid stable?

~~~
ParadigmComplex
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.

