Most likely that's the controller running on Windows and does not necessarily mean the those games have yet been ported to SteamOS/Linux. Mostly because they're not yet available on Steam for Linux. I expect they will be, though, as the other Counter Strike games the first Portal has been ported already. Keep in mind those franchises are owned by Valve who is pushing this whole thing, though - the fact they will be ported doesn't directly mean COD or MOH will be ported any time soon.
Nebula in this context is a company who has released a product called "Nebula One," which is a server setup. Nebula One runs OpenStack and some proprietary Nebula software.
The target audience for Nebula One are the companies who are inclined to outsource server stuff to "the cloud" - ie, don't want to worry about the work/responsibility to maintain their own servers - but also don't want to have their information in the hands of a third party such as Amazon. Nebula One is intended to be a "it just works" server solution for many cloud-computing type things, such as managing many VMs or data redundancy. Nebula also provides support for the product. Ideally, the best of all worlds: ease-of-use and dedicated-support of clouds without the privacy or dependency issues.
I kind of think of it as the RHEL of cloud-related-server stuff. If you're savvy enough and do-it-yourself enough, you might be able to build and maintain something comparable yourself. However, some companies are in a position where paying another company for the setup work and support is a better choice.
> That article is horrible.
Agreed.
> Is it just me, or does this new 'cloud' tool have absolutely nothing to do with OpenNebula (which abbreviates itself ONE), a competitor to OpenStack?
I'm not familiar with OpenNebula, but from the sound of it - no, they're not related, beyond being a competing codebase. They might have a similar etymology, though. NASA worked on a "Nebula" computing platform which is related to OpenStack - I wouldn't be surprised if OpenNebula also spun off from NASA's Nebula. The CEO of Nebula-the-company worked on (headed?) NASA's Nebula.
There's also an Eve Online group called "Nebula". The product "Nebula One" has some legitimate promise IMO, but the name is ripe for causing confusion.
It auto-updates on Linux as well, however it does it in an interesting fashion. Essentially, the.deb package Valve put out (and distros are considering throwing in their repos) simply installs an installer. When one runs "steam" for the first time, it downloads and installs steam locally in his or her home folder. It can thus update as non-root.
In this projects IRC channel, someone proposed appending a -pg to it, since the point of this fork is to revert udev to what it was before it went insane. I find this prospect quite amusing and hope it picks up.
Oddly enough, Micro-USB was specifically designed with the exact complaint you have in mind. While it is smaller than the Mini-USB it replaced, that was secondary to its main purpose, which was to improve durability. Not only is it supposed to be more durable in terms of the number of times it can be inserted/removed, but it is also designed such that, when it fails, the (most likely cheaper) cord will be the part to break rather than the (most likely more expensive) device. I'd cite a source but I can't pick which one - look up any documentation on Micro-USB and you'll read the same thing.
For what it is worth, in my personal experience, I have not seen any such issues with Micro-USB. The only times I can recall in which I've seen them fail have been because the cord itself - well away from the connector - was damaged, such as by a wheeled chair rolling over them. However, I have seen a number of the just replaced Apple connectors causing issues. For example, this summer, I've seen an iPod where the connection on the device - not the cord - was bent to one side so that the cord-side connector would not fit in. Mind you this wasn't so terrible - I repaired it with a thin knife and a careful hand - but still, in my personal experience, the old Apple connector has a significantly worse record than the Micro-USB.
While I'm blessed enough to have full functionality of both my arms, I have repeatedly run into situations where I am significantly more skilled than those I am playing with, and to keep things interesting, restrict myself to one hand when playing a number of games. While I am significantly better with both hands, it is not impossible to be somewhat competitive in many games with only one hand. Occasionally I've found myself (successfully) using these techniques in tournament matches when I feel a sufficient need to make a point. Moreover, I have in the past found myself with a pressing desire to play a new game, but absolutely no spare time, so I double-up eating with playing. For example, I beat (the gamecube version of ) The Legend of Zelda: Twilight Princess entirely with only my left hand, such that I could use my right hand to eat during my lunch breaks.
I figured I could give some advice as a result of my experiences.
First off, I should note that I primarily do this on a Nintendo Gamecube controller (as I am an avid Super Smash Bros Melee fan), but in my experiences they do translate well to the Xbox360 controller. I have not given serious consideration to a Playstation controller, and naturally this will not translate to keyboard/mouse.
Secondly, I should note that I've yet to find a good way (assuming an unmodified controller) to have immediate access to both sticks and all of the shoulder buttons simultaneously. Typically, you'll have to limit yourself to delayed access to something. This is a limited issue in some games (e.g.: fighting games), but can be very pressing in other games (e.g.: first person shooters).
You did not state in TFS which hand you have lost, and so I will cover both hands. There are two main grips I use, depending on the specific situation in the specific game.
The primarily left handed grip: Sitting down, place the controller on your left thigh or knee. Place your pinky on the left stick, thumb on the right stick, and pointer finger over the main part of the face buttons. To access shoulder buttons, have either your pinky or pointer finger reach over and around the controller to the appropriate button. This will most likely feel awkward at first, especially using the pinky on the left control stick, but I assure you with practice it is quite possible to become adept at it. The biggest limitation is the reach time for the shoulder buttons.
The second grip left-handed grip is a modification of the way the left hand typically holds the controller. I have often heard this referred to as "the left-handed claw". Instead of using the thumb on the left stick, slide it down to the directional pad, and use the pointer finger on the stick. If you try to also cover both left shoulder buttons you'll find you only have the pinky to provide support - rest the controller on your leg. The obvious limitation here is significant lack of access to the right side of the controller. I use this in SSBM for wavedashing when needed (jumping with up).
It is quite possible to switch between these two grips on-the-fly. While you'll have at best a delayed access to any given input device on the controller, you will have access to everything. With practice, I'm reasonably confident someone with one hand could progress through many 360/NGC games built with the intention
The right hand is, in my opinion, significantly harder to use, but not impossible:
The primarily right-hand grip: Rest the controller on your right thigh or knee. Place your pointer finger on the left stick, your ring finger on the right stick, and your pinky over the main face buttons. Like the left hand, reach over the controller with either your pointer finger or pinky when needing to reach the shoulder buttons.
I cannot think of any games that are completely playable with only the right-hand claw (see the left hand claw above for reference), so I won't really cover it. I should note that, when playing with both hands, I use the right-handed claw. However, most
As fun as it is to bash Microsoft, they're not the only ones who do this. Presumably there is some technical reason why this is done, but I am at a loss for what this would be. Would someone be able to explain to me the reason why such limits are put in place?
It seems with modern computer capability that absurdly long passwords would be trivial. The hashed password length would be the same irrelevant, so I can't see storage space as the issue. The only other idea which comes to my mind is the computational difficulty of hashing the passwords, but even that has to be trivial by today's standards, even with millions of users hitting the servers. Why not go overboard and just allow several kilobytes worth of password?
I could be mistaken, but I believe you are thinking of the sequel to A Fire Upon the Deep, A Deepness in the Sky. Both of the books are wonderful. A third book in that universe is now out, but I've not had the chance to read it yet.
I see so in practice you don't think they'll end up forking too much in terms of dependencies. I think you're wrong there but at we'll know in a few years. I've had huge problems between supposedly identical Linux systems like RHEL 6 and Cent 6 on things like their minor differences on Java libraries. I know Slackware had horrible problems with Gnome.
Not exactly, but close, at least if I am understanding you correctly. The idea is that things which have dependencies which would be issues across distros will simply reference their dependencies from their own distros. So if you run a RHEL6 java program, it will use RHEL6 java libraries, and if you run a CentOS6 java program, it will run CentOS6 java libraries. I should emphasize, however, that you still end up with an extremely large number of things that can interact transparently; my favorite example of this being an RSS reader which can open a web page in a browser, where both the RSS reader and browser are from different distributions.
We are down to a fundamental "will it work"?
I readily admit the idea I've had is quite a bit out there, and so I do not fault those who do not take me at my word, but I can honestly say that, for the use-cases I have tested for the past few years, it works. The current release is more or less identical to what I have been using for the last nine months on all of my personal computers on a regular basis.
So anyway project sounds cool. I know there are people who really really want to be able to combine features from different distributions.
I load up my X. Do I load X11R6 or R7? Presumably I can pick.
It will default to a native version if available (so if you're in Mint's/bin/bash when you startx, you'll get mints X11, if it has it installed), and if it is not available, it will pick the first one from a list of the other distros installed which has the command. I intend to expand this at some point, but that's how it is at the moment, and it as worked surprisingly well. Moreover, it should be noted that you can explicitly pick which distros version of something is run with the brc command at any time.
I'm not sure there isn't kernel stuff here but lets assume not.
Depending on the software you want in the various distros, there could very well be both an upper and lower bound on the kernel version, but the range is sufficiently large that I've never actually run into it.
So I pick R7 and that doesn't work with my Gnome 2 which was built around R6.
Surprisingly, most of the software I have tried this with is fairly standardized and backwards compatible. While I am sure you can find things which will conflict, it has been surprisingly rare in my experiences thus far. I have played quite a bit with running older software in newer X11s, and newer software in older X11 with surprising success. The pool of software I have tried this with may not be large enough to catch issues which do exist, though; I admit such things could very well be out there. In the worst case scenario, should they exist, and if I cannot find some other solution, you can always just use them in the groups they have to be bunched in. So maybe one version of a DE has to be paired with one version of X11 - you can still pick from every other distro for just about every other thing.
I guess my question to you would be why use Linux as the base here? Why not us an OS which just spins off these various distributions as virtual?
I'm not completely sure I understand what you're asking. I'll throw some answers around and see if one of them gets lucky. I'm using the Linux kernel because it has the widest range of userland software which could benefit from this approach. While there is quite a bit of value in, say, the BSDs, Bedrock's system will not really benefit them nearly as much.
Visualization creates a substantial amount of overhead, and purposefully separates to a degree which harms the integrated feeling I wanted to give. For example, once Valve brings Steam to Linux, I'd like to play some 3D games that would not work well in a virtual machine, but work fine with the chroot system I'm using. Moreover, the way that the programs from different distros can all interact as though they are all in the same distro would be significantly harder to achieve with visualization.
If that did not answer your questions, feel free to ask again, preferably rephrasing them and/or pointing out how I've failed to properly explain the matter at hand, and I'll do my best to try again.
Hi since it sounds like you are actually familiar.
Yes, I'm the lead(/only) dev. I've had at least one person note distaste at the fact I failed to specify this in the summary - I apologize for not making it clear.
How is Bedrock going to do this?
I know it is against slashtdot tradition, but if you RTFA you'll have what I hope is a sufficient answer. Irrelevant, I'll take a crack at answering your questions directly:
By manipulating the filesystem (through chroots and bind mounts) as well as PATH manipulation, Bedrock will make arbitrary commands from other Linux distributions which are on disk available in a fairly transparent fashion.
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.
This is very true. What I'm doing is grouping executable with the rest of their distro. Each program gets the dependencies it needs from the same repository it came from. There are downsides to this, such as a substantial amount of duplication, but it results in a nice clean way to ensure everything has what it needs to run. The magic comes in the way I use special stuff in the PATH and bind mounting to ensure that most things in one distro can run in others.
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.
Since the entire client distro is available on disk, I just let it figure out dependencies as it normally would, making this largely a non-issue.
If I've failed to explain it, and the linked explanation does not suffice, feel free to ask me again, with an emphasis on pointing out how my explanation failed.
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.
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...
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.
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.
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.
I understand that you have integrated stuff to make it easy to use a chroot.
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.
But if you aren't addressing the system start,
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.
then why not having Bedrock as a simple package for let's say Debian
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:
replace GNU tools by busybox (a poor choice, IMO),
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'm not dismissing your work here, I'm trying to understand your design choices, as I wouldn't have do it the same way.
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.
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 other thing to consider is the many potential points of failure when a distro relies on other
distros with dissimilar distribution methods, library tools, packaging tools, expected directory structure, etc. Just one little change can cause a huge ripple effect. Arch, last month changed directory structures followed by changing/lib to/usr/lib. It bricked a lot of machines requiring much manual messing around to get things back on track.
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:
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.
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 provides network before setting up NFS, but I cannot ensure Bedrock provides the specific upstart init. Moreover, you explicitly said
(and I'm not even talking about dependency booting...
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.
So OF COURSE it wont be resolved anytime
, because Ubuntu guys don't care, they use Upstart.
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.
Now, Bedrock doesn't address these issues
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.
it's of very low interest to me
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.
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. 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:
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.
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.
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.
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.
(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.
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.
Slashdot Mirror
Most likely that's the controller running on Windows and does not necessarily mean the those games have yet been ported to SteamOS/Linux. Mostly because they're not yet available on Steam for Linux. I expect they will be, though, as the other Counter Strike games the first Portal has been ported already. Keep in mind those franchises are owned by Valve who is pushing this whole thing, though - the fact they will be ported doesn't directly mean COD or MOH will be ported any time soon.
> So what exactly is Nebula?
From what I understand (and I may be mistaken):
Nebula in this context is a company who has released a product called "Nebula One," which is a server setup. Nebula One runs OpenStack and some proprietary Nebula software.
The target audience for Nebula One are the companies who are inclined to outsource server stuff to "the cloud" - ie, don't want to worry about the work/responsibility to maintain their own servers - but also don't want to have their information in the hands of a third party such as Amazon. Nebula One is intended to be a "it just works" server solution for many cloud-computing type things, such as managing many VMs or data redundancy. Nebula also provides support for the product. Ideally, the best of all worlds: ease-of-use and dedicated-support of clouds without the privacy or dependency issues.
I kind of think of it as the RHEL of cloud-related-server stuff. If you're savvy enough and do-it-yourself enough, you might be able to build and maintain something comparable yourself. However, some companies are in a position where paying another company for the setup work and support is a better choice.
> That article is horrible.
Agreed.
> Is it just me, or does this new 'cloud' tool have absolutely nothing to do with OpenNebula (which abbreviates itself ONE), a competitor to OpenStack?
I'm not familiar with OpenNebula, but from the sound of it - no, they're not related, beyond being a competing codebase. They might have a similar etymology, though. NASA worked on a "Nebula" computing platform which is related to OpenStack - I wouldn't be surprised if OpenNebula also spun off from NASA's Nebula. The CEO of Nebula-the-company worked on (headed?) NASA's Nebula.
There's also an Eve Online group called "Nebula". The product "Nebula One" has some legitimate promise IMO, but the name is ripe for causing confusion.
Steam automatically installs itself into $HOME so it can self-update.
It auto-updates on Linux as well, however it does it in an interesting fashion. Essentially, the .deb package Valve put out (and distros are considering throwing in their repos) simply installs an installer. When one runs "steam" for the first time, it downloads and installs steam locally in his or her home folder. It can thus update as non-root.
In this projects IRC channel, someone proposed appending a -pg to it, since the point of this fork is to revert udev to what it was before it went insane. I find this prospect quite amusing and hope it picks up.
Oddly enough, Micro-USB was specifically designed with the exact complaint you have in mind. While it is smaller than the Mini-USB it replaced, that was secondary to its main purpose, which was to improve durability. Not only is it supposed to be more durable in terms of the number of times it can be inserted/removed, but it is also designed such that, when it fails, the (most likely cheaper) cord will be the part to break rather than the (most likely more expensive) device. I'd cite a source but I can't pick which one - look up any documentation on Micro-USB and you'll read the same thing.
For what it is worth, in my personal experience, I have not seen any such issues with Micro-USB. The only times I can recall in which I've seen them fail have been because the cord itself - well away from the connector - was damaged, such as by a wheeled chair rolling over them. However, I have seen a number of the just replaced Apple connectors causing issues. For example, this summer, I've seen an iPod where the connection on the device - not the cord - was bent to one side so that the cord-side connector would not fit in. Mind you this wasn't so terrible - I repaired it with a thin knife and a careful hand - but still, in my personal experience, the old Apple connector has a significantly worse record than the Micro-USB.
While I'm blessed enough to have full functionality of both my arms, I have repeatedly run into situations where I am significantly more skilled than those I am playing with, and to keep things interesting, restrict myself to one hand when playing a number of games. While I am significantly better with both hands, it is not impossible to be somewhat competitive in many games with only one hand. Occasionally I've found myself (successfully) using these techniques in tournament matches when I feel a sufficient need to make a point. Moreover, I have in the past found myself with a pressing desire to play a new game, but absolutely no spare time, so I double-up eating with playing. For example, I beat (the gamecube version of ) The Legend of Zelda: Twilight Princess entirely with only my left hand, such that I could use my right hand to eat during my lunch breaks.
I figured I could give some advice as a result of my experiences.
First off, I should note that I primarily do this on a Nintendo Gamecube controller (as I am an avid Super Smash Bros Melee fan), but in my experiences they do translate well to the Xbox360 controller. I have not given serious consideration to a Playstation controller, and naturally this will not translate to keyboard/mouse.
Secondly, I should note that I've yet to find a good way (assuming an unmodified controller) to have immediate access to both sticks and all of the shoulder buttons simultaneously. Typically, you'll have to limit yourself to delayed access to something. This is a limited issue in some games (e.g.: fighting games), but can be very pressing in other games (e.g.: first person shooters).
You did not state in TFS which hand you have lost, and so I will cover both hands. There are two main grips I use, depending on the specific situation in the specific game.
The primarily left handed grip: Sitting down, place the controller on your left thigh or knee. Place your pinky on the left stick, thumb on the right stick, and pointer finger over the main part of the face buttons. To access shoulder buttons, have either your pinky or pointer finger reach over and around the controller to the appropriate button. This will most likely feel awkward at first, especially using the pinky on the left control stick, but I assure you with practice it is quite possible to become adept at it. The biggest limitation is the reach time for the shoulder buttons.
The second grip left-handed grip is a modification of the way the left hand typically holds the controller. I have often heard this referred to as "the left-handed claw". Instead of using the thumb on the left stick, slide it down to the directional pad, and use the pointer finger on the stick. If you try to also cover both left shoulder buttons you'll find you only have the pinky to provide support - rest the controller on your leg. The obvious limitation here is significant lack of access to the right side of the controller. I use this in SSBM for wavedashing when needed (jumping with up).
It is quite possible to switch between these two grips on-the-fly. While you'll have at best a delayed access to any given input device on the controller, you will have access to everything. With practice, I'm reasonably confident someone with one hand could progress through many 360/NGC games built with the intention
The right hand is, in my opinion, significantly harder to use, but not impossible:
The primarily right-hand grip: Rest the controller on your right thigh or knee. Place your pointer finger on the left stick, your ring finger on the right stick, and your pinky over the main face buttons. Like the left hand, reach over the controller with either your pointer finger or pinky when needing to reach the shoulder buttons.
I cannot think of any games that are completely playable with only the right-hand claw (see the left hand claw above for reference), so I won't really cover it. I should note that, when playing with both hands, I use the right-handed claw. However, most
As fun as it is to bash Microsoft, they're not the only ones who do this. Presumably there is some technical reason why this is done, but I am at a loss for what this would be. Would someone be able to explain to me the reason why such limits are put in place?
It seems with modern computer capability that absurdly long passwords would be trivial. The hashed password length would be the same irrelevant, so I can't see storage space as the issue. The only other idea which comes to my mind is the computational difficulty of hashing the passwords, but even that has to be trivial by today's standards, even with millions of users hitting the servers. Why not go overboard and just allow several kilobytes worth of password?
I could be mistaken, but I believe you are thinking of the sequel to A Fire Upon the Deep, A Deepness in the Sky. Both of the books are wonderful. A third book in that universe is now out, but I've not had the chance to read it yet.
I see so in practice you don't think they'll end up forking too much in terms of dependencies. I think you're wrong there but at we'll know in a few years. I've had huge problems between supposedly identical Linux systems like RHEL 6 and Cent 6 on things like their minor differences on Java libraries. I know Slackware had horrible problems with Gnome.
Not exactly, but close, at least if I am understanding you correctly. The idea is that things which have dependencies which would be issues across distros will simply reference their dependencies from their own distros. So if you run a RHEL6 java program, it will use RHEL6 java libraries, and if you run a CentOS6 java program, it will run CentOS6 java libraries. I should emphasize, however, that you still end up with an extremely large number of things that can interact transparently; my favorite example of this being an RSS reader which can open a web page in a browser, where both the RSS reader and browser are from different distributions.
We are down to a fundamental "will it work"?
I readily admit the idea I've had is quite a bit out there, and so I do not fault those who do not take me at my word, but I can honestly say that, for the use-cases I have tested for the past few years, it works. The current release is more or less identical to what I have been using for the last nine months on all of my personal computers on a regular basis.
So anyway project sounds cool. I know there are people who really really want to be able to combine features from different distributions.
I'm glad you feel that way :D
I load up my X. Do I load X11R6 or R7? Presumably I can pick.
It will default to a native version if available (so if you're in Mint's /bin/bash when you startx, you'll get mints X11, if it has it installed), and if it is not available, it will pick the first one from a list of the other distros installed which has the command. I intend to expand this at some point, but that's how it is at the moment, and it as worked surprisingly well. Moreover, it should be noted that you can explicitly pick which distros version of something is run with the brc command at any time.
I'm not sure there isn't kernel stuff here but lets assume not.
Depending on the software you want in the various distros, there could very well be both an upper and lower bound on the kernel version, but the range is sufficiently large that I've never actually run into it.
So I pick R7 and that doesn't work with my Gnome 2 which was built around R6.
Surprisingly, most of the software I have tried this with is fairly standardized and backwards compatible. While I am sure you can find things which will conflict, it has been surprisingly rare in my experiences thus far. I have played quite a bit with running older software in newer X11s, and newer software in older X11 with surprising success. The pool of software I have tried this with may not be large enough to catch issues which do exist, though; I admit such things could very well be out there. In the worst case scenario, should they exist, and if I cannot find some other solution, you can always just use them in the groups they have to be bunched in. So maybe one version of a DE has to be paired with one version of X11 - you can still pick from every other distro for just about every other thing.
I guess my question to you would be why use Linux as the base here? Why not us an OS which just spins off these various distributions as virtual?
I'm not completely sure I understand what you're asking. I'll throw some answers around and see if one of them gets lucky. I'm using the Linux kernel because it has the widest range of userland software which could benefit from this approach. While there is quite a bit of value in, say, the BSDs, Bedrock's system will not really benefit them nearly as much.
Visualization creates a substantial amount of overhead, and purposefully separates to a degree which harms the integrated feeling I wanted to give. For example, once Valve brings Steam to Linux, I'd like to play some 3D games that would not work well in a virtual machine, but work fine with the chroot system I'm using. Moreover, the way that the programs from different distros can all interact as though they are all in the same distro would be significantly harder to achieve with visualization.
If that did not answer your questions, feel free to ask again, preferably rephrasing them and/or pointing out how I've failed to properly explain the matter at hand, and I'll do my best to try again.
Hi since it sounds like you are actually familiar.
Yes, I'm the lead(/only) dev. I've had at least one person note distaste at the fact I failed to specify this in the summary - I apologize for not making it clear.
How is Bedrock going to do this?
I know it is against slashtdot tradition, but if you RTFA you'll have what I hope is a sufficient answer. Irrelevant, I'll take a crack at answering your questions directly:
By manipulating the filesystem (through chroots and bind mounts) as well as PATH manipulation, Bedrock will make arbitrary commands from other Linux distributions which are on disk available in a fairly transparent fashion.
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.
This is very true. What I'm doing is grouping executable with the rest of their distro. Each program gets the dependencies it needs from the same repository it came from. There are downsides to this, such as a substantial amount of duplication, but it results in a nice clean way to ensure everything has what it needs to run. The magic comes in the way I use special stuff in the PATH and bind mounting to ensure that most things in one distro can run in others.
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.
Since the entire client distro is available on disk, I just let it figure out dependencies as it normally would, making this largely a non-issue.
If I've failed to explain it, and the linked explanation does not suffice, feel free to ask me again, with an emphasis on pointing out how my explanation failed.
Excellent, happy to hear it. Do not hesitate to ask for help or offer feedback, even criticisms.
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.
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...
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.
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.
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.
I understand that you have integrated stuff to make it easy to use a chroot.
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.
But if you aren't addressing the system start,
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.
then why not having Bedrock as a simple package for let's say Debian
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:
replace GNU tools by busybox (a poor choice, IMO),
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'm not dismissing your work here, I'm trying to understand your design choices, as I wouldn't have do it the same way.
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.
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!
The other thing to consider is the many potential points of failure when a distro relies on other distros with dissimilar distribution methods, library tools, packaging tools, expected directory structure, etc. Just one little change can cause a huge ripple effect. Arch, last month changed directory structures followed by changing /lib to /usr/lib. It bricked a lot of machines requiring much manual messing around to get things back on track.
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".
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.
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 provides network before setting up NFS, but I cannot ensure Bedrock provides the specific upstart init. Moreover, you explicitly said
(and I'm not even talking about dependency booting...
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.
So OF COURSE it wont be resolved anytime , because Ubuntu guys don't care, they use Upstart.
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.
Now, Bedrock doesn't address these issues
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.
it's of very low interest to me
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.
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. 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.
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.
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.
(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.
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.