Slashdot Mirror
Bedrock Linux Combines Benefits of Other Linux Distros
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."
Yet another Linux distribution.....
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?
world was created 5 seconds before this post as it is.
Is nvidia as good as on arch?
Number of Linux Distributions Surpasses Number of Users
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).
http://xkcd.com/927/
Not quite a standard, but I'd say it's close enough.
-1 RMS fanatic.
Some apps are WYSIWYG. Some others are WYSIWTF.
Your point is correct, however they're at release 1 alpha. I'm pretty sure the logo is not the first thing someone makes.
I apologize, I literally just learned HTML/CSS within the last week to create the website. I've had other people offer to create a website for me who actually know what they're doing with respect to website creation - once they're done I'll gladly switch it away from what I'm sure is a poor example of a proper website.
What I am knowledgeable about is the content discussed within the website. Don't judge the book by its cover here, as I'm reasonably confident there is something unique in there.
"A witty saying proves nothing." - Voltaire
this is linux, not apple. not everyone focuses on marketing first.
this one is sure to go far! hell this might even be the one that brings linux to the desktop! woohoo! so excited!
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
Debian stable (rock solid stable)
packages from backports and packages from testing/unstable (new bleading edge)
apt-build (can do a make world, if you really want .05% more perf + hassle of building yourself)
ubuntu is mainly debian unstable, so compatibility with ubuntu is more or less given.
making it easy to do all at the same time is a design feature of debian
This seems to be based on the principle that if you want the strength of a tank, the performance of a sports car, and the economy of a hybrid you just lash a tank, a Ferrari and a Prius together and driving it will get you all three. I somehow doubt that the reality will live up to the promise.
Gentoo lets you do all of this....
Sigh. Start the flames of "zomg fun-roll-loops" and "takes too long to compile wah wah".
Well then, I guess I can trust Apple with the fate of the universe. Never did trust bash anyway.
Forward! -- Emperor Norton, 2012
To be fair, it looked fine to me - until I tried it in IE.
systemd is Roko's Basilisk.
Debian testing (i.e. Wheezy) already gives all the advantages outlined above.
Sounds great, I'm looking forward to the project becoming stable :)
This distro will cover everyone's requirements.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
Combined probably a few thousand at least. Check the user mailing list, forum and chat activity of a few of them.
Seriously, what's the point of you demonising people who care about stuff you don't? That's the first step in many bad agendas and mindsets employed around the world: claim that your opponents are not real human beings.
Throwing in rhetorical questions and answering them with false facts doesn't help either.
More like -1 MS shill masquerading as RMS fanatic.
this is linux, not apple. not everyone focuses on marketing first.
And with good reason. No amount of marketing can improve shoddy work.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
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.
Luckily, there is no "-1 RMS fanatic", "-1 disagree" or "-1 your worldview sux mine rox" moderation option.
I really, really like Debian. If Debian could do what Bedrock Linux can, I would have never tried to make Bedrock Linux. The issue is, however, that you can't install an arbitrary program from testing/unstable into stable.. Many of those packages are dependent on specific libraries which aren't available in stable. With Bedrock Linux, you can install and use packages from both, at the same time. I can run Squeeze's newsbeuter in Sid's X11 and have it open a window in Wheezy's iceweasel. It's all transparent and feels like one cohesive OS.
"A witty saying proves nothing." - Voltaire
In truth, there's limites to being able to install things that way- and down the rabbit hole of DLL/.so hell you go.
There's a reason for the dependencies and if you don't understand it, perhaps you shouldn't embrace something that "gets rid of it" in the manner you're describing there.
Main reason Valve's shipping for Ubuntu is that they've not gotten a handle on how to ship cross-distro capable installs and binary sets- so you pick a distro and run with it, much like all of the commercial vendors do when they start doing Linux support. Not a bad thing, but there's ways to do this that're not all obvious unless you've been steeped in how Linux actually works. Hopefully, I'll get them to work with me to show them HOW to do that. Now that the day-job's slowing down, I'll be getting back in touch with them on the subject... :-D
I really did not intend to be misleading in quite that way; if you truly feel that way, I apologize. I created something I feel is really neat and would like to share, and felt slashdot would be a great place to share it. You can check my UID - I'm not exactly new around these parts. I'm also not making any money on this - I'm not sure an advertisement is the best description of what this is.
"A witty saying proves nothing." - Voltaire
Well where's the focus then?
It can't be code quality or else we wouldn't be talking in a thread about a meta-distribution "designed" to cover can't-be-arsed-to-fix crap, would we?
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
I need benefits you insenstive clod!
- http://www.milkme.co.uk
hairyfeet is that you with the usual stating of the blatantly wrong as fact?
Yet ANOTHER fucking Linux distribution.
from the FAQ:
Why is there no installer?
It is an easy way to avoid the responsibility associated with partitioning or setting up a bootloader. A mistake in the former could easily delete valued data, and a mistake in the latter could just as easily ruin someone's day in other ways. By only providing instructions, if something goes wrong, it is quite easy to just say "I told you to be careful at that part" and remove responsibility from the Bedrock Linux developer.
Why should I not use Bedrock?
If you value stability/reliability, note that while this is a priority for Bedrock Linux, Bedrock Linux is still largely new and untested; a tried-and-true stable/reliable Linux distribution such as Debian or a Red Hat Enterprise Linux clone would likely be better suited.
and continued...
If you value security, note that Bedrock Linux probably has the highest attack surface of just about any Linux distribution, mostly because its attack surface is the sum of the attack surfaces of just about every other Linux distribution combine. While steps can be taken to alleviate this to some degree, ultimately, a locked-down Bedrock Linux can never truly reach the security offered by a locked-down standard Linux distribution.
this thing hits on every cliche of stupid open source projects! it's got to be a troll, i mean seriously...
I guess I see your point. You are trying to do something similar to below for folks who can't figure it out for themselves. If "folks who can't figure it out for themselves" is your target audience, I hope you have some sort of unified update system, so patches for all your chroot environments just work too, since these folks aren't likely to figure patching out for themselves, either. Good luck.
To answer your points:
Usually you can install packages from testing/unstable-- you can usually (very easily) build from the source package using the lib versions in stable-- if someone hasn't beaten you to it with backports.
Also, where I don't want my regular system polluted with bleeding edge libraries, but newer libs are needed, I just set LD_LIBRARY_PATH in a wrapper script to point to particular libs. This would also work with a chroot install of wheezy/sid with bins run outside the chroot, so can use prebuilt bins for wheezy/sid on stable, though never needed to do this.
I guess as a last resort, a wrapper to spawn an app in a chroot as you do. schroot makes this easy, but I haven't needed to do this in years. Prior to existance of schroot, ran wine and firefox 32 bit in a 32 bit chroot with wrapper scripts to make it seamless and work for unpriv user. Haven't seen anything in years that required something like this, though-- but I realize that doesn't mean it doesn't exist.
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 because that's the closest one I know of since it can run on top of any and all distros.
Promote true freedom - support standards and interoperability.
It should work on all the 10 billion other debian based systems and debian as well.
It's "napkin with boxes on it" business plan time again. It's bad enough resolving discrepancies between packages from similar architectures, such as Red Hat and Fedora, when the underlying script structures just took a turn for the weird. (Take a look at the new "systemd" toolkit for Fedora 17, which replaces SysV inint scripts and breoke *every single package* that used init scripts.)
Multiply this by the discrepancies in packaging between, say, SuSE and Red Hat (which have different naming conventions for X library packages and perl modules), and multiply by the differences between RPM based systems like Red Hat and "apt" based systems like Debian, and the discrepancies between Debian and Ubuntu, and you have a combinatorial problem, then add in the complexity of 3rd party repositories like ATrpms for Red Hat or Packman for SuSE.
If you think this is even remotely possible, go ahead and crossport any Debian utility that relies on the older verson ov mod_perl (and there are plenty) with any system that uses Apache 2.2.
I believe the phrase you were looking for is 'would *have*', my dear fellow.
If Debian could do what Bedrock Linux can, I would have never tried to make Bedrock Linux.
Then why not contributing to Debian the features of Bedrock? I don't think anyone would mind if there was a cool and easy way to run stuff from SID inside Stable...
Hopefully, I'll get them to work with me to show them HOW to do that.
"Hi Valve, it's me. You know, Anonymous Coward. I'd like you to pay me money to tell you what you're doing wrong... hello? Hello?"
Now that the day-job's slowing down, I'll be getting back in touch with them on the subject...
... "Hi Valve, Anonymous Coward again. We got cut off - are your phones working ok? Hello? That's odd, it's happened again."
On the subject of dependencies, from what I understand, because Bedrock essentially has pretty much full distro installs in chroots, each distro uses its own libraries, so it's possible to have different library versions coexisting as applications will only load the libraries they are linked against - the particular chroot/$PATH/bind mount magic that Bedrock does takes care of it. As packages are installed using individual "client" distros package management tools, they will pull in whatever dependencies they need and install them in that "client" distro's chroot.
It seems quite elegant to me, although I haven't the patience to set it up myself as I'd effectively be administering 5 distros instead of one. It might be quite nice for a combined CentOS/Rawhide system though, kind of super-stable but with easily added bleeding edge bling.
We need another Linux distro like we one more politician ...
... 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 or /var/tmp (don't assume ... check and see). Copy the unpacked files into /opt/${NAME_OF_SOFTWARE} in the appropriate forms if they need to be modified or compiled at install time. Put any host-wide restricted-to-root config files in /etc/${NAME_OF_SOFTWARE}. Put the front-end starter script for it in /usr/local/bin. If daemons are involved, find the appropriate installer tool and call it, or hunt for an appropriate init directory (the install script will need to have some logic here to figure this out). And keep a log of all the steps performed, and a list of files installed, in a file named /var/log/${NAME_OF_SOFTWARE}/${yyyy}-${mm}-${dd}-${HH}${MM}-install.log.
And you can do BSD, too, though most likely with different executables. There aren't so many BSDs, so this part should be easier.
This is not that hard, people. Especially for programmers. Stop whining about Linux not being as boring as Windows is.
now we need to go OSS in diesel cars
Wouldn't this be better as a compatability layer on top of each of the targeted distros?
I think I shall wait to see how it matures. Leading edge is fine but bleeding edge is not.
And with good reason. No amount of marketing can improve shoddy work.
Marketing can definitely sell shoddy work - or Windows wouldn't be around at all. Linux has better technology, Mac has more polish. Even Os/2 was somewhat better than windows at the time. But marketing rules the masses. Which is why windows prevail, and why many people believe it is "normal" for a computer to crash now and then or need crazy band-aid solutions such as "antivirus software".
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).
An ASCII Art logo? So it is a CLI distro?!
Gives the wrong impression right at the start.
That's what I thought too. Putting chroot management on top of Debian stable to run other newfangled stuff or stuff from other distros without messing up the main OS sounds very promising. And once you don't need it any more, rm -rf. Done.
thegodmovie.com - watch it
Don't let the AC get to you. If I'd created a new Linux distro I'd want people to know about it too. Your post was ok in my book.
Koans and fables for the software engineer
They'll get a proper logo once negotiations with Hanna Barbara are finished.
When our name is on the back of your car, we're behind you all the way!
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 installed without conflicts, name changes, or repackaging.
The easiest way to do this would be to change the package manager to support a two level namespace instead of a flat one. So instead of simply installing the latest version of the package from your distribution, you could install a (largely) compatible version with the same name from a different source, and the package manager would pull in the necessary libraries from that source (or other ABI compatible sources) and track them as such. As long as the libraries themselves were appropriately versioned, the library packages would install without conflicts.
That wouldn't come close to letting you install any package from any distribution (in some cases the dependencies would be too complicated, or the ABI too different in subtle ways), but it would allow you to install more recent versions of most packages from the newer versions of the same distribution (including beta, rawhide, testing, versions etc) without problems in most cases, and many ABI compatible packages from other distributions as well.
this is linux, not apple. not everyone focuses on marketing first.
Everyone coming here with the question "what is this, why should I care?" reads your response and goes back to what they were doing.
I hope that was the effect you were going for.
I don't see the major advantage of using this over AUR and ABS or whatever Gentoo is portaging. I'm sure Ubu base will be happy for bleeding edge or a slab menu, and it's a wonderful dream concept, but what are you offering to those that know how to compile already? Sure, simple keystrokes are nice but how are you cutting out the bloat?
I'm not blasting you for your effort. Everyone should grab a LFS manual and give their shot at a distro at one time or another (if nothing else you gain a lot of knowledge about how the kernel and toolchains work). Just curious how you plan to get from "massive hodge-podge of distro pulling" to "everyone will want to use it".
and it's all in this little bottle
It's called "-1, Overrated"
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
An ASCII Art logo?
I'm just much, much better with text editors than I am with image editors. I wanted to focus more on the actual distro than the artwork. Other people have offered to spruce the website
So it is a CLI distro?!
Not really, no. While it is extremely minimal out of the box for technical reasons, the intent is you add quite a bit more to it, including whatever desktop environment you feel like.
Gives the wrong impression right at the start.
It is definitely not for everyone. I like it, but I know people I've explicitly recommend not try it. If a CLI scares you off, this is not for you - at least not at the first alpha release.
"A witty saying proves nothing." - Voltaire
It's less expensive than a bj from your whore mother.
There's a reason for the dependencies and if you don't understand it, perhaps you shouldn't embrace something that "gets rid of it" in the manner you're describing there.
I was under the impression I did understand much of the rationale behind the reason why things are set up the way they were, and that my solution is fitting. For example, one reason is that if everything was packaged with all of the libraries it needed, and there was a security issue in one of the libraries, all of the packages would have to be updated. By using shared libraries as most Linux distributions tend to, this ensures that once the problem has been fixed for the library, all of the packages which use it benefit. If this was not done, and one package failed to be updated, security issues could arise. Bedrock Linux simply groups things by the libraries the sets of libraries they are dependent on, so that the same principle is largely applied: The library only has to be updated once per distro that uses it as opposed to for every single package. So long as one stick with respectable distros for the clients, the issue isn't quite a big one here.
If you feel there are other large reasons I am overlooking for why the established manner is as it is and why Bedrock Linux fails to properly meet them, I would be very grateful if you could explain them to me or direct me to where I could learn more.
Main reason Valve's shipping for Ubuntu is that they've not gotten a handle on how to ship cross-distro capable installs and binary sets
My experiences with other proprietary software which attempts to ship cross-distro capable installs is sadly strewn with various headaches when I'm at either end of the stability-vs-cutting-edge spectrum. I mostly cited Steam as a potential use as it is a reasonably current example that could benefit that many slashdotters are well aware of. Should Valve managed to properly distribute something which works on everything from ScientificLinux to Arch, I will be all the happier.
"A witty saying proves nothing." - Voltaire
If "folks who can't figure it out for themselves" is your target audience,
It's not, at least not at the moment. The intent is more about automating things than making things easier. People who cannot compile things for themselves will likely have quite a lot of headaches with Bedrock Linux, at least as early as it is.
I hope you have some sort of unified update system, so patches for all your chroot environments just work too, since these folks aren't likely to figure patching out for themselves, either.
I've got a system in place, although it needs quite a bit of work. The idea behind it is to ease updates - a single command updates all of the clients.
Good luck.
Thanks, I'll need it. I do not consider this a small undertaking.
Usually you can install packages from testing/unstable-- you can usually (very easily) build from the source package using the lib versions in stable-- if someone hasn't beaten you to it with backports.
For quite a while I used Debian Stable with a mix of backports and my own custom compiled packages. However, as time went on, I wanted more and more things which were not available in backports and I didn't care to have to manually compile every single one. The only solution I found which let me get everything I wanted at the same time was chroots. I just kept playing with it until I felt I had something novel and worth sharing.
Also, where I don't want my regular system polluted with bleeding edge libraries, but newer libs are needed, I just set LD_LIBRARY_PATH in a wrapper script to point to particular libs. This would also work with a chroot install of wheezy/sid with bins run outside the chroot, so can use prebuilt bins for wheezy/sid on stable,
I toyed with this as well and found that it was also far to much work for the frequency I ended up using it.
though never needed to do this.
I think that's where the fundamental issue lies. It is not that there is a preferable alternative to what I've done so much as I've got a different set of desires than you do, and Bedrock Linux does not give you anything you did not already have. If this is the case, I fully encourage you to stick with what you know and like.
schroot makes this easy, but I haven't needed to do this in years
I actually used schroot for this for quite some time, but ended up dropping it as I couldn't find a way to statically compile it easily, and without that I couldn't find a sane way to ensure it can run transparently in every client without statically compiling it. Capchroot was a delightful solution which fit the bill, so long as it was paired with scripts to automate the various mounts necessary.
"A witty saying proves nothing." - Voltaire
I do not feel I am necessarily making a foolproof case for requiring a new distro - I could see legitimate discussion about the validity of simply building a system on top of an existing distro. Ultimately, it was because I just kept tweaking my early experiments with Debian Squeeze base and a Sid chroot until it no longer resembled any existing distros sufficiently to justify sharing their names.
"A witty saying proves nothing." - Voltaire
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.
Space game using normal deck of cards: http://BattleCards.org
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?
This doesn't answer my question: why don't you contribute this to Debian?
I don't think anyone would mind if there was a cool and easy way to run stuff from SID inside Stable...
There already is a relatively clean way to run things from Sid from within Stable called schroot. If all you want is to run things from within Sid in Stable, that should suffice. I used it early on in the experiments that lead up to Bedrock. I ended up discarding it because (1) I wanted to be able to run a command without worrying where the parent program is, and (2) I wanted this to work cleanly with just about any distro, not just Debian-based ones. I ended up concluding this required the ability to statically compile the chroot program (in this case schroot), and found with that requirement capchroot was preferable. Regarding your original question:
Then why not contributing to Debian the features of Bedrock?
Largely because I felt, to meet all of my goals (including the ones I described in the previous response), I needed to change a sufficient number of things that there isn't anything left to call Debian. It wouldn't run in Debian, it would replace it. If I limited myself to something which could run on top of Debian, it would be more or less the same thing as schroot. I do not propose that I could write schroot better than the current maintainer.
If that does not suffice, it would be helpful if you could explain where or how you feel I am failing to answer your question, as at the moment I'm at a loss as to where my explanation is lacking.
"A witty saying proves nothing." - Voltaire
I've not yet looked at what you have to offer, but based off my UID and your own, I do consider you 'new around these parts' - I'm not exactly an old fish in this pond myself. Maybe that's a part of my conservative nature.
That said, I intend to look at what you have to offer and assess it non-impartially. If it sucks, it sucks - you learned a lesson and had a good time, accomplishing something personally. My resume has a number of such experiences.
The best of luck to you.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
There already is. It's called pinning. It works quite well, even with things which are fairly low level, like pinning.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
I've not yet looked at what you have to offer, but based off my UID and your own, I do consider you 'new around these parts' - I'm not exactly an old fish in this pond myself. Maybe that's a part of my conservative nature.
It's all relative, but I'm more than willing to admit you've got me beat soundly.
That said, I intend to look at what you have to offer and assess it non-impartially. If it sucks, it sucks - you learned a lesson and had a good time, accomplishing something personally. My resume has a number of such experiences.
I would like to request that, if you do not find it to your satisfaction, you contact me to explain why that is, both so that I can have a chance to clear up anything I have failed to present adequately (there have been multiple cases of this thus far, sadly) and so that I can attempt to remedy the issues I recognize as such (or, if I cannot fix them, so I can learn the appropriate lesson). Note that I do not consider "this is of no use to me" a design fault, as it is intended to target a niche audience, but baring that I would love the chance to fix any problems you find, even if they are fundamental to the project.
The best of luck to you.
Thank you!
"A witty saying proves nothing." - Voltaire
Thanks, its a lot more clear now. However, could you explain why you couldn't do like schroot, but "be able to run a command without worrying where the parent program is", inside Debian? What prevents you to do this?
It's easy for arch independent sutff, it's a major pain for things that depend on a particular ABI. For example, try to run Pidgin from SID without rebuilding it...
Well, it's barely better than the ASCII Art, but feel free to use this if you want: http://i.imgur.com/U8fjM.png
Also, I like the fact you're trying to address the bag of spilling (package managers) without adding more spill (yet another package manager).
I've tested your alpha - it's unpolished but it works. I wish the best luck.
Nerdy news for your nerdy needs? http://www.soylentnews.org Soylent News is people!
Will try out your distro when I got the time to build up another test machine
Muchas Gracias, Señor Edward Snowden !
Being a Gentoo user, I already have quite a bit of flexibility rergarding stability vs. experimental packages. Still, Bedrock appeals to me. In my case, for the abillity to get other-distro-specific candy.
I have a question that's not handled by the FAQ, so I'll ask it here before I dive into the docs (though I probably will dive in anyway). On my machines, I already keep multple "/" partitions around with different distros installed (rarely used, but just in case). Could I just put Bedrock on one of these "/" partitions and have it "combine" the others that are already installed? Or does it want me to install the distros it "manages" from scratch? Combining what I've already built into one streamlined meta-distro is attractive, and just might be worth the effort.
When I say "have it combine", I of course wouldn't expect anything automagic (i.e. extra configuration is acceptable). But is this even possible?
Wow. The perfect mix of trolls. Timecube, mycleanpc, gnaa, apk... this is great!
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
...... pardon me for butting in, but:
Would another view on the subject be:
It's all open source. It's already sitting there if someone else wants to use it.
p.s. -- i'm actually very interested in this. My interest in switching to linux was already growing rapidly, and then ubuntu blew a cylinder.
So far your descriptions are making me feel like, "wasn't this what the modular nature of linux was supposed to do before it became so tribal ??"
Hi since it sounds like you are actually familiar. How is Bedrock going to do this? For example to get cutting edge features to work you often need to put in destabilizing patches to the kernel or use newer more buggy versions of core libraries and utilities. This is why installing some little thing from Debian unstable on a Debian stable box can trigger 100 package upgrades as chains of dependencies get worked through.
Source / binary mixtures i think is a really good thing as the BSDs have shown. So I agree with you there, and am glad that's coming to Linux. Though I will point out that can expose quite a few bugs related to build order that otherwise wouldn't have mattered. You end up having to debug some complications in how related families of packages register changes with one another in very complex ways. Essentially it means creating an entirely new level or complex special instructions on a per package basis which make automatic dependency resolution not work as well.
Mechanically I can see chroot as a mechanism but I don't see how it can be this light in practice.
but based off my UID and your own, I do consider you 'new around these parts'
Then you're being silly, frankly. He might not be as old as ye olde ancients or mere demi-gods like yourself, but it's blingdingly obvious that he didn't register an account this morning just to post about his new distro.
His UID is in the 900k range. Mine is in the 600k range, and ISTR I registered it some time in 2004, after reading AC for quite a while. Being pessimistic, the OP could easily have been here 5 years. If you think that's "new around here" you're being silly and engaging in UID dick-waving.
SJW n. One who posts facts.
I'm sure the devs will have a gay old time.
Yabba Dabba Doooooo!
Mine is in the 600k range, and ISTR I registered it some time in 2004, after reading AC for quite a while. Being pessimistic, the OP could easily have been here 5 years. If you think that's "new around here" you're being silly and engaging in UID dick-waving.
/slowclap
I'm reasonably confident I do not understand your question, as I feel as though this comment should answer that question, yet I believe you already read it. Would you mind restating the question, or specifying how the prior comment failed to answer it?
If I give up a number of things, including but not limited to the three items I've mentioned in the prior comment, it sure is possible, but it'd be far less pleasant of an experience.
If there is sufficient interest, and time is available, I could most definitely consider providing something which has as much functionality I can muster which could sit on top of a major distro, although a sufficient amount of functionality would be lost that I could not honestly say I would enjoy using it.
"A witty saying proves nothing." - Voltaire
Excellent, happy to hear it. Do not hesitate to ask for help or offer feedback, even criticisms.
"A witty saying proves nothing." - Voltaire
A new metadistro. I think it's awesome, and possibly the start of something big.