I'm not intentionally avoiding it. I am not supporting only sysvrc, that was simply an example. Ubuntu's upstart, as another example, works fine. I don't have systemd or openrc on my system at the moment to give you a definitive "yes they work as well", I fully plan to add support for them. There are a lot of Gentoo fans who have offered to assist me.

I've been using this stuff successfully for years I've been using the first alpha release for the last nine months alone before I released it. From those experiences, I have found that manually solving boot dependencies has been a trivial matter. Perhaps I'm still misunderstanding the exact issue at hand, or maybe I've just been absurdly lucky and I'll run into significant issues later.

Not necessarily easy, but to make it all feel cohesive. But perhaps I'm over analyzing that specific sentence and you are aware of my goal.

I should indicate here that, as far as I can tell, I am, at least to my satisfaction. Perhaps not sufficiently for your purposes, at least not with the first release.

I think I delivered a satisfactory answer to this and most of the rest of your post in another thread of the conversation. If I haven't, I'll take another crack at it. It could very well be my logic for why I have not done this is faulty and I just didn't quite grasp the reason why yet. A few other items I would like to address:

I wanted to keep the base as simple as possible With busybox, I can update nearly the entire userland by replacing a single file. The functionality busybox is lacking is a non-issue, as this is provided by clients. I do not intend for anyone to actually use the busybox commands for much at all. When I used to use Debian as a base so long ago, I found that upkeep for Debian was far higher than necessary. I never really used it - it just did the init and that was it. However, when a release was EOL'd, I had to go ahead and try a dist-upgrade or reinstall, neither of which I found appealing, as the side effects could be far reaching. Replacing one busybox binary with another is much, much cleaner.

I appreciate that fact. You've been more than patient with my thus far unsatisfactory answers.

I'm replying to quite a few people mostly out of excitement. Good or bad, I've gotten a lot of attention. I do not necessarily care to convince everyone, or even anyone - I have received a pleasantly large amount of support as it is - but I would like to be certain that, if there is a legitimate issue with Bedrock Linux, I understand it. Most of the criticisms have been, as far as I can tell, due to misunderstandings about what the project is and does. There is a very real possibility that there is a legitimate issue hidden somewhere in there, and I would like to root it out so that I can resolve it. I know of no better way to do this.

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

It's all relative, but I'm more than willing to admit you've got me beat soundly.

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.

Thank you!

I'm doing my best to cover these issues as they arise. Before the /usr move, I was reasonably confident I had most of the major ones squashed, but the /usr move has caused some issues.

However, I actually consider this a relative strength of Bedrock. I am putting a high priority on ensuring that if a client is unexpected broken, the system continues to function. In some respects this makes Arch-on-Bedrock more reliable than straight Arch, although with the alpha-state Bedrock is in at the moment I can't drop the qualifier "in some respects".

Ah, my apologies. While I feel I answered your question, perhaps I did not frame my answer correctly. Let me first tackle something I missed in the original question first:

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:

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.

Perhaps we're misunderstanding each other.

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. Moreover, you explicitly said

The fact you pointing out with great emphasis that I failed to address dependency issues in response to a statement which explicitly excluded dependency issues leads me to believe we are misunderstanding each other. If the misunderstandings are on my end, I apologize. I admit I could be dense and simply misunderstanding you - in fact, that's most likely the case - but it seems you're a bit scattered in your direction with the questions/responses. If you give me something very concrete and specific to respond to I will be more likely to succeed.

Agreed, sadly. Ubuntu puts very little priority on things outside of their core interest - people who use chroots aren't exactly their target audience. None the less I have a functional workaround for the issue.

I'm not sure exactly what issues you are referring to. While getting Ubuntu's daemons to work is not as clean as I would like, but works just fine. 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.

That's fine. Your particular needs could very well differ from mine, and if this does not benefit you, I certainly encourage you to stick with something which does. As I stated before, I agree that this a relatively niche project. However, I do not approve of the way you are misrepresenting what Bedrock Linux is and is capable of, as there are others like me who do have a use for such things who may be discouraged from trying the project out after reading your comment.

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. At the risk of confusing the issue, I will make an analogy against package managers: What they do can very well be done manually, but if you wish for anything remotely complicated it is significantly easier to simply use a package manager. Stating that "apt-get remove [package]" is a waste when you can just run find against timestamps for when the package was installed and just rm the resulting files is either significantly lacking in imagination or disingenuous. Now, if you have no need for package managers as you don't add/remove things very often, well, that's fine. But that doesn't mean the project is sufficiently irrelevant to dismiss it out of hand and discourage others who could very well benefit from it.

Early on, I used Debian stable and played with Sid in a chroot. However, a few issues arose which I could not find a good way to solve to my satisfaction without making my own distro:

1. This meant I had to keep the base Debian up to date, and when the release was eventually EOL'd, I would have to either dist-upgrade or reinstall. By making the base as small as possible, it minimized the need for upkeep. I can potentially keep an absurdly large uptime while still dist-upgrading almost the entire userland. If a dist-upgrade fails, it's a non-issue, as I just cp -rp'd the chroot before doing so.
2. Attempting to tie the init systems of every other distro into Debian's was a scary proposition, especially since I figured odds were good Debian would change their init system (and I was correct). Having my own init seemed a better option.
3. The system I use to ensure things like shells and PATH work could be potentially ruined by package upgrades if Debian's package manager had control of such things without quite knowing what they were

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.

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

Thanks, I'll need it. I do not consider this a small undertaking.

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.

I toyed with this as well and found that it was also far to much work for the frequency I ended up using it.

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.

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.

(1) A mix of dissatisfaction with the status quo and determination. Be careful when mixing such powerful agents.

(2) Mostly by messing with filesystem calls via chroots and bindmounts. I make the whole system feel cohesive with specially crafted PATHs and some scripts. Hopefully the description here satisfies your curiousity.

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.

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.

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 maybe compiz from Arch will crash on me when I feel like playing with it. If you do not feel that meets what I described, it could be I failed to describe it properly, and if so, I apologize.

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

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.

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.

I gave an example here 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 that I ended up creating the discussed topic, and figured it was worth sharing.

Would you mind elaborating on what drove you to that conclusion? I feel all that fits the first alpha of just about any project, honestly, but it could very well be I'm simply not viewing it with the same mindset others are.

I am quite serious with this project, and in no way trolling - I just want to share something I created which I found useful. If you could explain what made you draw that conclusion, I'll try to remedy it if I can.