8 ms·

Bedrock Linux

242 points by duggieawesome 13y ago

wesleyac 13y ago
Very cool, but I'm happy with Arch.
- delluminatus 13y ago
  How do you know if someone uses Arch Linux? Don't worry... they'll tell you! (BTW I use Arch)
  - zidar 13y ago
    We're like the vegans of the linux world.
    - vhost- 13y ago
      I'm a vegan in the Linux world.
      - jessaustin 13y ago
        You seem to conform to the stereotype! b^)
  - derefr 13y ago
    What do you call a quiet Arch user? A Slackware user. (I've used both at various points; no enmity intended.)
    - vezzy-fnord 13y ago
      As a Slack user, I can confirm this.
      - nekopa 13y ago
        Seconded.
    - sliverstorm 13y ago
      Does Arch trace its history to Slack?
  - antocv 13y ago
    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 13y ago
      So I take it you are an Arch user?
      - antocv 13y ago
        You mad bro?
    - akulbe 13y ago
      The Arch Linux community that you see in Freenode/#archlinux... there's LOT of elitism coming from a few very vocal individuals. "Earnestly" is very nice, very helpful. I don't know if community is genuinely important to Arch Linux, or not. It may, in fact, be their aim to be an elitist and cloistered few... who knows. If community is important to them... put the technical arguments aside long enough to take a page from Canonical's playbook. Ubuntu _gets_ community. Like it, or not... there's more to life than being the smartest/best coder in the room. If you're an asshole, your talents quickly fade. mad coder skills & genuinely nice > mad coder skills Flame on, folks. I've already mentally prepared myself for the inevitable insults and vitriol.
    - 59nadir 13y ago
      You never get to make the same joke for users of other distros, though, because it's pretty much always the arch users who feel the need to mention "cool, but I run arch so I'm all set" or whatever. It's the most obnoxious way to not contribute to a discussion at all.
- 59nadir 13y ago
  Why did you feel the need to comment at all?
zidar 13y ago
"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 13y ago
  I guess they mean: system packages which are stable, but apps that are bleeding-edge.
  - danieldk 13y ago
    Not at all. Watch the video, it gives a pretty good demonstration of what it does: http://www.youtube.com/watch?v=MuYMBCcgs98 http://www.youtube.com/watch?v=MuYMBCcgs98
  - zidar 13y ago
    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.
    - sajithdilshan 13y ago
      Exactly, I mean I would be on cloud nine if I could run gnome 3.10 apps on Debian wheezy
      - ParadigmComplex 13y ago
        (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 :)
dilipray 13y ago
it made my day. I'm ready to dive. :)
- ParadigmComplex 13y ago
  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.
Zardoz84 13y ago
Interesting... I will need to try it.
- ParadigmComplex 13y ago
  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.
ineedtosleep 13y ago
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 13y ago
  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.
JSno 13y ago
how could it be possible since not any relative new version of kernel can be claimed rock solid stable?
- ParadigmComplex 13y ago
  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.
chamakits 13y ago
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.
swinglock 13y ago
Interesting. Which kernel does it end up using? Could it handle packages which wants a special kernel or different modules for different kernels?
- ParadigmComplex 13y ago
  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.
- rplacd 13y ago
  "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.)
  - ParadigmComplex 13y ago
    > "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!
eeadc 13y ago
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.
- general_failure 13y ago
  Thanks for this. But be definition, the current approach is never the next generation approach.
- ParadigmComplex 13y ago
  > 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.
bachback 13y ago
very nice. what are some of the wider/long-term implications of this?
sdfjkl 13y ago
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).
- contingencies 13y ago
  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)
  - ParadigmComplex 13y ago
    > 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 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.
  - zanny 13y ago
    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.
codex 13y ago
In this distribution, are shared libraries really shared, or duplicated?
- ParadigmComplex 13y ago
  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 13y ago
    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 13y ago
      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.
gsarrica 13y ago
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 13y ago
  > 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 13y ago
    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 13y ago
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 13y ago
  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.

Bedrock Linux

242 points by duggieawesome 13y ago

wesleyac 13y ago

Very cool, but I'm happy with Arch.

delluminatus 13y ago
How do you know if someone uses Arch Linux? Don't worry... they'll tell you! (BTW I use Arch)
- zidar 13y ago
  We're like the vegans of the linux world.
  - vhost- 13y ago
    I'm a vegan in the Linux world.
    - jessaustin 13y ago
      You seem to conform to the stereotype! b^)
- derefr 13y ago
  What do you call a quiet Arch user? A Slackware user. (I've used both at various points; no enmity intended.)
  - vezzy-fnord 13y ago
    As a Slack user, I can confirm this.
    - nekopa 13y ago
      Seconded.
  - sliverstorm 13y ago
    Does Arch trace its history to Slack?
- antocv 13y ago
  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 13y ago
    So I take it you are an Arch user?
    - antocv 13y ago
      You mad bro?
  - akulbe 13y ago
    The Arch Linux community that you see in Freenode/#archlinux... there's LOT of elitism coming from a few very vocal individuals. "Earnestly" is very nice, very helpful. I don't know if community is genuinely important to Arch Linux, or not. It may, in fact, be their aim to be an elitist and cloistered few... who knows. If community is important to them... put the technical arguments aside long enough to take a page from Canonical's playbook. Ubuntu _gets_ community. Like it, or not... there's more to life than being the smartest/best coder in the room. If you're an asshole, your talents quickly fade. mad coder skills & genuinely nice > mad coder skills Flame on, folks. I've already mentally prepared myself for the inevitable insults and vitriol.
  - 59nadir 13y ago
    You never get to make the same joke for users of other distros, though, because it's pretty much always the arch users who feel the need to mention "cool, but I run arch so I'm all set" or whatever. It's the most obnoxious way to not contribute to a discussion at all.
59nadir 13y ago
Why did you feel the need to comment at all?

zidar 13y ago

"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 13y ago
I guess they mean: system packages which are stable, but apps that are bleeding-edge.
- danieldk 13y ago
  Not at all. Watch the video, it gives a pretty good demonstration of what it does: http://www.youtube.com/watch?v=MuYMBCcgs98 http://www.youtube.com/watch?v=MuYMBCcgs98
- zidar 13y ago
  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.
  - sajithdilshan 13y ago
    Exactly, I mean I would be on cloud nine if I could run gnome 3.10 apps on Debian wheezy
    - ParadigmComplex 13y ago
      (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 :)

dilipray 13y ago

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

ParadigmComplex 13y ago
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.

Zardoz84 13y ago

Interesting... I will need to try it.

ParadigmComplex 13y ago
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.

ineedtosleep 13y ago

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 13y ago
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.

JSno 13y ago

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

ParadigmComplex 13y ago
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.

chamakits 13y ago

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.

swinglock 13y ago

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

ParadigmComplex 13y ago
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.
rplacd 13y ago
"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.)
- ParadigmComplex 13y ago
  > "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!

eeadc 13y ago

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.

general_failure 13y ago
Thanks for this. But be definition, the current approach is never the next generation approach.
ParadigmComplex 13y ago
> 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.

bachback 13y ago

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

sdfjkl 13y ago

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

contingencies 13y ago
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)
- ParadigmComplex 13y ago
  > 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 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.
- zanny 13y ago
  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.

codex 13y ago

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

ParadigmComplex 13y ago
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 13y ago
  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 13y ago
    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.

gsarrica 13y ago

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 13y ago
> 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 13y ago
  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 13y ago

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 13y ago
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.