Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux

Bedrock Linux Combines Benefits of Other Linux Distros 179

Posted by samzenpus from the best-of-all-worlds dept.
First time accepted submitter Paradigm_Complex writes "From the distro's front page: 'Bedrock Linux is a Linux distribution created with the aim of making most of the (often seemingly mutually-exclusive) benefits of various other Linux distributions available simultaneously and transparently. If one would like a rock-solid stable base (for example, from Debian or a RHEL clone) yet still have easy access to cutting-edge packages (from, say, Arch Linux), automate compiling packages with Gentoo's portage, and ensure that software aimed only for the ever popular Ubuntu will run smoothly — all at the same time, in the same distribution — Bedrock Linux will provide a means to achieve this.' The timing of this release is particularly nice for those who were excited to hear that Valve was bringing Steam to Linux, but were disappointed that it was targeting Ubuntu as Ubuntu was not their distro of choice. If it works on Ubuntu, it should work fine on Bedrock Linux, while still ensuring the majority of the system feel very, very similar to Fedora or Slackware or whatever you prefer."
This discussion has been archived. No new comments can be posted.

Bedrock Linux Combines Benefits of Other Linux Distros More

Bedrock Linux Combines Benefits of Other Linux Distros

Comments Filter:

  • Sounds great! (Score:5, Funny)

    by skipkent ( 1510 ) on Sunday August 05, 2012 @09:51AM (#40886167)

    I'm sure the devs will have a gay old time.

  • so, If I wanted to say run Wine, install node.js and nvidia drivers, would it be just using some search tool for them all and pressing install?

    • Re:anyone tested the alpha? (Score:5, Informative)

      by Paradigm_Complex ( 968558 ) on Sunday August 05, 2012 @10:46AM (#40886451)
      At the moment, I don't yet have a package manager manager (not a typo), but it is on the TODO and will get there eventually. For the time being, just run the package manager from the client Linux distribution of your choice and install the packages as you normally would. "apt-get install wine" or "pacman -S wine" or "yum install wine" or whatever else you'd like - take your pick.

      I've yet to try installing the nvidia drivers through a package manager, as I expect that might make assumptions about the kernel which won't be true. Thus far I've just installed it manually from the drivers provided on nvidia's website. Installing it via a package manager may be possible eventually, just isn't there quite yet.
    • While I'm sure you intended that as a way of de-valuing yet-another-distro, if you actually take a look at what it does, it is strengthened by the variety of other distros out there. Know two niche distros that both have features you want? Bedrock will (most likely) give you both of them at the same time. If there was One True Distro, Bedrock would have no value.

      • Haters gonna hate. My suggestion would be to stop wasting your time over such non-constructive comments, and complete the work you have taken at hand. ;)

        It's pretty awesome, though.

        • I do have a hard time not feeding the trolls. I keep trying to rationalize something which isn't necessarily acting rationally.

          And thanks :D
      • Aw, come on, sense of humour needed, AC at 14:59 was linking to a joke. After following the link I need a new keyboard.

        And same goes for whoever modded him as Troll.

      • In fact the closest I can think to bedrock is "rootless gobolinux" on a stable distro, bedrock is different enough. Possibly GP was ironic, not trolling. The poor sap deplores multiple distros and prefers to submit his PC experience to what UI designers at MS, Apple (and why not, Canonical) decide it's best for the user^H^H^H^H trapping of users in their own differentiated user interface. Personally I'd rather switch distros every day of the week.

  • Minimal busybox LFS with chroots (Score:5, Interesting)

    by Anonymous Coward on Sunday August 05, 2012 @10:03AM (#40886235)

    The tl;dr version is that this "distro" is just an installation manual for a linux-from-scratch style install of a kernel, busybox, and little else (think initrd-style minimal system) plus chroots under which you can install regular distros.

    While a novel concept, this is clearly a niche idea. At best I could see it useful to the developer who wants to test his packages across multiple distros, but you can already do that with a standard "host" distro and chroots for "guest" distros. It also does nothing (at least yet) to deal with the fact that each "client" will want/expect its own daemons to be running, but lots of them will be system-exclusive (e.g. anything to do with devices or networking).

    • Re:Minimal busybox LFS with chroots (Score:5, Informative)

      by Paradigm_Complex ( 968558 ) on Sunday August 05, 2012 @10:41AM (#40886423)
      You've missed the way it integrates the various chroot'd clients together, which is really the whole point. See the second point here [osu.edu]. That was literal barely anything more "apt-get install compiz && pacman -S xorg", throwing compiz in the .xinitrc and running "startx". As another example, it can have an RSS reader from one distro open a page in a browser from a completely different distro, transparently; it all feels like one single cohesive Linux distribution.

      I do agree it is niche. It's not for everyone. However, I can't be the only one who has interest in the fact that I can have the vast majority of the system running Debian, nice and stable unchanging, yet still grab something from Arch with nothing more than a single pacman command if I feel like playing with something new.

      Other than Ubuntu/Upstart's expectation to have its specific init running (which isn't technically a daemon, I don't think), I've yet to run into issues with conflicting distro-specific daemons. However, until very recently I'm the only one whose actually run it, and I'm sure people will find issues I've not yet thought up. That's why it's still in alpha.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        I think this poses a wonderful opportunity to make Debian work well with systemd for those who want it. The interesting scenario this poses is that there are 3 or more competing init programs (sysvinit, upstart and systemd) which puts an extra burden on package maintainers. You wouldn't simply choose an arbitrary init using /etc/alternatives, because the system would have to boot up in order to do that. Therefore, the only logical solution would be to make it possible for all of them to coexist, perhaps usi

      • Why do you say "only Ubuntu/Upstart"? All distro, nowadays, are using different init systems. Fedora is using systemd, Ubuntu uses upstart, Gentoo uses OpenRC, and Debian still uses sysvrc/insserv. None are compatible with each other. In other words: there's no way any daemon will work properly (and I'm not even talking about dependency booting...). How do you deal with that?
        • Most daemons from, say, sysv, aren't really dependent on the init system. They're just programs that init happens to run when it feels like it. You can run them manually whenever. For example, if you want to run Debian Squeeze's cups, you can run "/etc/init.d/cups restart" absolutely irrelevant of what the init is.

          The daemons Ubuntu uses talk to init for some reason. If init doesn't talk back, they refuse to run. See here [osu.edu] for my specifics on it, which links to a bug report [launchpad.net] on the matter that I'm dou

          • Most daemons from, say, sysv, aren't really dependent on the init system.

            The daemons themselves no. But the way to start them is highly dependent on the system you are running under.

            They're just programs that init happens to run when it feels like it.

            That's a terrible way to describe dependencies. Eg, you can't run for example NFS mounts if you don't have network, and can't do network without local FS, etc.

            The daemons Ubuntu uses talk to init for some reason. If init doesn't talk back, they refuse to run. See here [osu.edu] for my specifics on it, which links to a bug report [launchpad.net] on the matter that I'm doubtful will be resolved within the foreseeable future.

            Not only Ubuntu. Fedora and Gentoo does this as well. This is because they moved from a sequence based thing to an event based thing. For example, stop doing "start these daemons after syslog is started and some random delays", but do "start th

            • Perhaps we're misunderstanding each other.

              They're just programs that init happens to run when it feels like it.

              That's a terrible way to describe dependencies. Eg, you can't run for example NFS mounts if you don't have network, and can't do network without local FS, etc.

              You're missing a bit of context with that. That statement was in direct response to your request for me to explain why I singled out Ubuntu/Upstart. It was intended in contrast to how Ubuntu's/Upstart's daemons function, as sysv daemons can all run just fine in a chroot more or less irrelevant of host (provided the dependencies are met), but Ubuntu's daemons cannot (due to dependence on a specific init which the host may not use). I can go ahead and ensure Bedrock

              • You're missing a bit of context with that. That statement was in direct response to your request for me to explain why I singled out Ubuntu/Upstart. It was intended in contrast to how Ubuntu's/Upstart's daemons function, as sysv daemons can all run just fine in a chroot more or less irrelevant of host (provided the dependencies are met), but Ubuntu's daemons cannot (due to dependence on a specific init which the host may not use). I can go ahead and ensure Bedrock provides network before setting up NFS, but I cannot ensure Bedrock provides the specific upstart init.

                You aren't answering my specific point. Ubuntu and CentOS v6 are both using Upstart. Fedora uses systemd. Gentoo uses OpenRC. If you support only sysvrc, then you're supporting only Debian...

                If you are referring to automatic dependency resolution for client daemons at boot, then no, the first alpha release does not provide any means for this quite yet. It is a relatively low priority at the moment (as specifying these things manually is absolutely trivial), and the project is yet quite young.

                Yes, that's what I was referring to. *NO* it's not trivial at all. The stuff from systemd is very different form initrc, and you wont succeed in having something that works just by specifying "things by hand". You really need to address the issue of events, not only the order used to start daemons.

                it's not better than managing chroot by hand, by myself.

                If you truly believe this, then I have almost certainly failed in properly explaining it, and I am at a loss as to where I have lead you astray. While all of this is certainly possible manually, it is significantly more work for the particular usage cases for which I utilize it.

                I understand that you

        • Re: (Score:2)

          by CAIMLAS ( 41445 )

          Debian has been running systemd for quite some time [debian.org]. You can still use sysvrc nomenclature, but it'll complain, but it's systemd from now on forward.

          • Yes, but it's not the default (the default is sysv-rc, and it will for Wheezy as well). So there's no way to send a bug against a package because it doesn't have a good support for systemd, which is the problem. However, I do hope that we will switch to either OpenRC or systemd for Jessie (yes, that's the name of Wheezy+1).

      • Re:Minimal busybox LFS with chroots (Score:4, Interesting)

        by MurukeshM ( 1901690 ) on Sunday August 05, 2012 @12:44PM (#40887323)

        I disagree that it is niche. With two (admittedly major) things, this could be the Linux distro to take over the desktop. A decent setup program and corporate backing. Seriously. If I could Google how to do X and be able to apply the solution for any distro on mine, just think about how much would that simplify things for grand mas and granddads. Corporate backing to push vendors to pre-install it and get companies to use it. I understand that it's a long way out. A unified front. That said, I wish you the best and I hope that I can get to contribute in some way in the future (too much of a n00b/scaredy-cat to venture into an open-source project now).

        • I disagree that it is niche.

          I know the ins and outs of creating a distro more than I understand people - I could be underestimating the demand for this. I'd sure love to see a large community grow around Bedrock Linux - I hope you're correct.

          With two (admittedly major) things, this could be the Linux distro to take over the desktop.

          While I would absolutely love for that to be true, I'm doubtful it's feasible to get this to be sufficiently simple and user friendly. While I could do things to make it much easier to install, there are fundamental aspects which I don't quite have sufficient imagination to foresee as ever being

  • Debian testing (i.e. Wheezy) already gives all the advantages outlined above.

    • Re:Debian Testing (Score:4, Interesting)

      by Paradigm_Complex ( 968558 ) on Sunday August 05, 2012 @11:04AM (#40886575)
      Then you misunderstood the advantages outlined above. It might be my fault for explaining them.

      I really, really like Debian. I like the fact that, once released, it really doesn't change for well over a year. Once I have it set up I can just let it run. However, it becomes out of date fast - if I want some new toy that just came out and isn't in Debian backports. With Bedrock Linux, I can have 95% of the system be Debian except for that one package I want from Arch, which I will get from Arch. Take a look here for what may be better examples.

      If you still feel Wheezy covers this, reply again and I'll try to explain it differently. This is really nothing like Wheezy at all. Unless you want it to be, of course, then it is almost exactly like Wheezy.

      • However, it becomes out of date fast

        That would be debian stable (squeeze), not debian testing (wheezy).
        Debian testing has packages which are much more up to date than ubuntu's.

        You may also choose to use Debian unstable (sid).

        • Re:Debian Testing (Score:4, Informative)

          by Paradigm_Complex ( 968558 ) on Sunday August 05, 2012 @11:48AM (#40886889)
          Well, the issue then is that testing and unstable aren't quite stable enough for me. I want something which I can learn and set up, then leave running for years. Debian stable could do that, but neither testing nor unstable could.

          However, at times I also want to play with the newest goodie from Debian Sid. I don't want to reboot, I don't want to use a VM, I just want to run a program from Sid. With Bedrock Linux, I can do that: I can have a system which is almost entirely Debian Stable, except for the packages I want from Sid when I want them. Any library compatibility issues one would normally have trying to get a .deb from Sid into Stable are non-issues with Bedrock Linux.

          Add on to that that I can use Gentoo's portage to relatively easily keep a specific package customized to my specific tastes. Say I don't like dbus, but I want firefox - Debian's iceweasel is dependent on dbus. I could just get it from Gentoo with the flag set to exclude dbus. Yet everything else would be Debian.

          At the same time, I am 100% library-compatible with Ubuntu, so for projects like sage mathematics [sagemath.org], which I know provides packages for Ubuntu [xmission.com], I can use those with absolutely no worry that they won't work. Debian Testing cannot do that.

          • Well, the issue then is that testing and unstable aren't quite stable enough for me.

            Unstable, I'd understand. It's there exactly for the purpose of uploading libraries and hold them for the transition period before everything goes at once in testing. But testing? How many times did you have issues with it? What issues exactly?

            I can have a system which is almost entirely Debian Stable, except for the packages I want from Sid when I want them

            This is what we call a backport. dget the .dsc file, dpkg-source -x that one, then build with dpkg-buidpackage. And that's if the backport doesn't exist yet in backports.debian.org. If you really don't want to do that (because there's too many new libs to depend on),

            • Unstable, I'd understand. It's there exactly for the purpose of uploading libraries and hold them for the transition period before everything goes at once in testing.

              Isn't that what 'experimental' is for?

              • No. Experimental is either for uploading packages which you don't want to see migrating from SID to Testing. This is useful especially at the time of freeze of testing (like right now), either for new upstream versions which includes a lot of changes (see for example yum which I uploaded recently in Experimental), or for totally new packages, or even for things which you aren't sure of the quality (eg: not fit for a release).

            • But testing? How many times did you have issues with it? What issues exactly?

              Stable has two definitions in this context that I can think of: (1) reliability and (2) lack of changes. I want something which stays the same. I do not necessarily want to keep myself up to date on the changes going on if I don't have time for it. I want something that stays the same for extended periods of time. However, I don't always want that - occasionally I do have the free time to play with something cutting edge, and so I do.

              This is what we call a backport. dget the .dsc file, dpkg-source -x that one, then build with dpkg-buidpackage. And that's if the backport doesn't exist yet in backports.debian.org

              I used to do that, but I got tired of it. Bedrock's system is signifi

          • Re: (Score:2)

            by CAIMLAS ( 41445 )

            You can do the 'firefox without dbus' thing fairly easily without leaving debian (stable), too, you know: compile it from a src package. It's not as straightforward, no. But it doesn't necessitate the complexity you're put in place to do so.

            That said, there may be an inherent security benefit to doing so.

            • Yes, but I would like to automate the process with portage, both because Firefox updates with a relatively high frequency and because it is not nearly the only package which I would like compiled with special tweaks.

              If that were the only reason I wanted Bedrock Linux's system, I agree Bedrock Linux is far to complicated to really justify its existance. However, it is only one item in a long list of things I can do with Bedrock Linux with relative ease once it is set up compared to any other (single) Lin

      • Re: (Score:2)

        by allo ( 1728082 )

        don't you think commenting "but we are better and you do not understand anything" under each post makes your distribution idea more interesting?
        Your idea is okay, not very usable for the most people, but a nice project. But advocating it in the way you're doing at the moment, you will get many people who hate it, because you tried to force it on them.

        • I don't think I quite follow what you are trying to say.

          don't you think commenting "but we are better and you do not understand anything" under each post makes your distribution idea more interesting?

          I really have no idea what prompted this. I think I came up with a nice out-of-the-box solution to a problem I found, but beyond that I don't really think anyone working on the project is necessarily "better" than anyone else. To be frank, you're all strangers I don't know well enough to compare myself too.

          Your idea is okay, not very usable for the most people, but a nice project.

          This much I think I follow.

          But advocating it in the way you're doing at the moment, you will get many people who hate it, because you tried to force it on them

          In no way do I intend to force this on anyone. Personally I felt it was a relatively niche project. I expected quite

      • If you still feel Wheezy covers this, reply again and I'll try to explain it differently. This is really nothing like Wheezy at all. Unless you want it to be, of course, then it is almost exactly like Wheezy.

        This is Bedrock Linux and welcome to you who have come to Bedrock Linux.
        Anything is possible at Bedrock Linux.
        You can do anything at Bedrock Linux.
        The infinite is possible at Bedrock Linux.
        The unattainable is unknown at Bedrock Linux.
        Welcome to Bedrock Linux.
        This is Bedrock Linux.
        Welcome to Bedrock Linux.
        Welcome.

  • Release Names (Score:4, Funny)

    by UmbraDei ( 1979082 ) on Sunday August 05, 2012 @11:31AM (#40886791)

    Where do the release names come from?
    All of the Bedrock Linux releases are named after characters from the Nickelodeon television program Avatar: The Last Air Bender.

    This is definitely the main reason I'll be trying it out.

  • Not being locked into one distro???? You're destroying the dreams of the distro company CEO's. STOP RUINING THEIR BUSINESS PLANS!

    Seriously, someone take a hint: Linux is supposed to be free, and no one should be locked into a particular distro. If you release a piece of software, you need to make it EASY to install on ANY distro, which means using a software installation standard. What's that? None exists? Then use Zero Install [0install.net] because that's the closest one I know of since it can run on top of any

  • It should work on all the 10 billion other debian based systems and debian as well.

    • Re: If it works on Ubuntu (Score:4, Insightful)

      by sylvandb ( 308927 ) on Sunday August 05, 2012 @12:39PM (#40887275) Homepage Journal

      Not really.

      Ubuntu has made a lot of changes (from the kernel and init system to the Unity desktop and notifications). If something depends on any of those changes it isn't going to be happy with debian.

      I have had nearly complete success the other direction though. So I would say if it runs on debian it should run on Ubuntu.

    • I gave an example here [osu.edu] that arose with software that worked fine in Ubuntu but not in Debian. There is quite a bit of software out there that is very picky about what libraries are used. If you get everything from your repository's package manager or compile them yourself, it's not a huge issue, but if it is not in your repository and you don't want to or can't compile it (e.g.: proprietary software such as Valve's Steam), you have to fall back to other options. This happened to me sufficiently often tha

  • ... and learn how to install and run on all the major Linux distributions. Don't worry about the weird ones. But the ones that are based on a major one generally should also work.

    Software does not necessarily have to come packaged in the same packaging system if it is not something other software might depend on. So I'm not talking about libraries here. Games are mostly going to fit in this category. Package it as a tarball, with out of band instructions or a script to untar the tarball in one of /tmp

  • Stability is not a feature you can install. Actually, having the newest up to date and experimental software is mutually exclusive with stability At best you can coose to use a stable version or a "beta" at runtime (i.e., without rebooting).

    • Typically, yes, but I'm using something a bit out of the norm. Want I initially wanted, and ended up creating, was a way to have the vast majority of the system be something known to be stable/reliable/unchanging (e.g.: Debian Stable), yet still have access to cutting-edge things (e.g.: Arch Linux) without overly much work involved to get them. The resulting system could have stability issues with respect to the Arch packages, but only them - I know that the init system from Debian will remain stable, but

  • There is no question that a system like Bedrock allows the ultimate in flexibility in terms of running programs from different distributions and the like. However, a multiple-distribution system like that adds a considerable amount of administrative complexity, making it relatively unlikely to be adopted by non-specialists.

    There is an intermediate step that would solve much of the problem here - change the way that Linux packages are packaged and accessed so that multiple versions of library packages can be

    • Re: (Score:2)

      by CAIMLAS ( 41445 )

      A specialist would (reasonably) reject such a system due to its needless complexity.

      Sorry, but complex is the enemy of secure. "I've got x installed for y but z innstalled for zy" doesn't cut it. Too many bushes to beat. KISS has its place, and that's most places. It would be better to completely and indepenently virtualize something than deal with the complexity of a homogenous 'oneness' system as proposed, from a sysadmin perspective.

      That said, it does have a certain novel appeal for the hobbist. It's a g

  • FreeBSD Jails (Score:3)

    by DarwinSurvivor ( 1752106 ) on Sunday August 05, 2012 @07:37PM (#40890209)
    So from what I can tell in the "Introduction" (haven't reald it all yet), it's sort of like FreeBSD's jails but without them getting their own IP addresses and being able to use a different distribution in each jail?

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close