Explain then why the majority of everyone is using Windows... (in other words: this is a silly question: who told you that the best tool for the job is always the one that is used?)
FreeNAS is based on FreeBSD, and boot speed (no matter what the OS) is based entirely on the hard drive speed + CPU speed + 'automagic' configuration.
This used to be truth, but it's not anymore. Look at modern init systems like upstart, OpenRC or Systemd. You'll see that these have very different results than what we could see using let's say sysv-rc. Note that there's a (huge) ongoing discussion inside Debian to choose what we will be using next (as Debian still uses the old sysv-rc thing).
That doesn't stop out of control inflation which is happening.
I can't deny it's there, everything nearly doubled in about 5 years. But this is unrelated to a lack of liquidity. That's quite the opposite in fact. There's only inflation when there's too much cash out...
In turn it doesn't stop food shortages, also happening.
What is this food shortage that everyone is talking about? Last time I checked, my local supermarket was full of food. Did you read some news about that in the "western" press? I heard nobody talking about it over here.
For the liquidity issues, you might have noticed in the last 3 weeks a large number of chinese firms suddenly dumping stocks.
I'd be happy to read about it! Please provide URLs if you have some.
Could you explain to the readers how it is possible that a country controlling its money creation and loans directly by the central government can go into debts?
FYI, even if you are married, the visa is for 6 months, not one year anymore. After 5 years of being married AND owning a real estate property you live in AND having 200 000 yuan blocked into a bank account AND living for more than 9 months in China during this 5 years period, you may get a green card. The application currently takes more than a year. Once you get it, it's a permanent living permit that has to be renewed every 10 years. With it, you can even create a local Chinese company under your own name.
but China is having some serious liquidity issues right now
Contrary to USA, China controls money creation through the central bank (which is controlled directly by the central party). The state also controls directly all banks that are giving out loans. It also has a lot of USD in reserve. So what liquidity issues are you talking about?
Yeah, right... Like, "we're sorry, we wont steal again from everyone, we swear!" Who's going to believe this? They already crashed the world economy, stolen money by the hundreds of billions, put so many people in the streets, and doing so much fraud that it's even hard to account all of them. And all they get is "it's ok, you just have to swear not to do it again". Oh, we're safe now, thank you!
And wash trading (eg: manipulating market prices by buying and selling at the same time), and MF global scandal, and naked short sellings, and accounting fraud, and selling Silver they don't have, and...
The list goes on, and on, and on, and on. But nobody "regulates" them. Or rather, should I say, nobody does JUSTICE, and put these crooks in jail.
So, when I read that [JP Morgan is] "in favor of tougher (and substantive!) regulations", one may wonder what this means.
Dimon is "sorry", yet pretends that he did "good things"? WTF!!! That's a joke, right?
Perhaps he's sorry that, as one of the biggest crooks in the world, he didn't go to jail? Or maybe he's sorry about the wash trading he did, and that he got only a 30k fine, for manipulating the crude oil markets? Or probably, he is sorry for JP-Morgan naked short selling on the Silver market? Or for emitting more bonds of Silver than they physically have? Or...
Come on, we all know what these data centers are for. They are for doing high frequency trading. It's been a long time that we all know such trades are destroying more wealth than it creates.
Such declaration is simply outrageous. We're tired of the financial terrorists. None have been punished, yet destroying jobs and lives by the millions, and proves of that accumulating. This one day will stop, once the general public understands what is going on. They'd better have strong necks when that day comes, because probably, their head will go off, just like in the French revolution.
In the mean time, since the people have lost their power over this disgusting "elite", everyone should play on the same game, and buy (physical) silver coins. Not only this is a very good investment, especially considering today's record low, but this also has the side effect of crashing JP-Morgan, since (as I wrote above) they did very dangerous bets, and already lost billions. As Max Keiser puts it: "GO GO! Silver liberation army!"
Well, it works pretty well mostly. Indeed, people traveling are helping a lot are helping to have a more strongly connected web of trust, and we encourage the ones that travel to have their keys signed by those who have the most signatures (which is what I'm trying to do when I go in Debconf, considering that there's very few DDs where I live, and that they don't travel often).
However, it works less good in countries where there's no DDs at all. I can remember a case of one poor guy that wanted his key signed in Cuba, but since there was no DDs in Cuba, and that that person couldn't travel (he had no budget, and anyway, couldn't go in USA because of restrictions). It was though, because we ask for at least one PGP signature (and strongly require 2 at least, preferably from well known and very active DDs). Such cases are very difficult to handle.
But voting in person is a lot harder. PGP keys are only a way to make it possible to trust the voters. It's a technical answer to a problem. I don't see how it makes it harder to use PGP (in fact, it's harder to do without it).
It's been years that inside Debian, we vote using our PGP keys, which are in the "web of trust" (eg: signed by our peers). People got to learn about signing each other keys, then voting isn't a problem at all.
By the way, I just realize that the login form in Slashdot tells me that my password should be from 6 to 20 chars long. 6 chars at least, ok, but why is there a limit on the length? Shouldn't Slashdot use password hashing, and then don't care about the length of my password?
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...
Yes, but it's not the default (the default is sysv-rc, and it will for Wheezy as well). So there's no way to send a bug against a package because it doesn't have a good support for systemd, which is the problem. However, I do hope that we will switch to either OpenRC or systemd for Jessie (yes, that's the name of Wheezy+1).
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?
You're missing a bit of context with that. That statement was in direct response to your request for me to explain why I singled out Ubuntu/Upstart. It was intended in contrast to how Ubuntu's/Upstart's daemons function, as sysv daemons can all run just fine in a chroot more or less irrelevant of host (provided the dependencies are met), but Ubuntu's daemons cannot (due to dependence on a specific init which the host may not use). I can go ahead and ensure Bedrock provides network before setting up NFS, but I cannot ensure Bedrock provides the specific upstart init.
You aren't answering my specific point. Ubuntu and CentOS v6 are both using Upstart. Fedora uses systemd. Gentoo uses OpenRC. If you support only sysvrc, then you're supporting only Debian...
If you are referring to automatic dependency resolution for client daemons at boot, then no, the first alpha release does not provide any means for this quite yet. It is a relatively low priority at the moment (as specifying these things manually is absolutely trivial), and the project is yet quite young.
Yes, that's what I was referring to. *NO* it's not trivial at all. The stuff from systemd is very different form initrc, and you wont succeed in having something that works just by specifying "things by hand". You really need to address the issue of events, not only the order used to start daemons.
it's not better than managing chroot by hand, by myself.
If you truly believe this, then I have almost certainly failed in properly explaining it, and I am at a loss as to where I have lead you astray. While all of this is certainly possible manually, it is significantly more work for the particular usage cases for which I utilize it.
I understand that you have integrated stuff to make it easy to use a chroot. But if you aren't addressing the system start, then why not having Bedrock as a simple package for let's say Debian, rather than having it being a full distribution, replace GNU tools by busybox (a poor choice, IMO), and all sort of things like that that we may not agree with? 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 really like your idea to be able to use apt / yum / emerge, all in one place, easily. But I don't see the point in having this inside a specific distribution. That's also, maybe, why multiple people pointed you at the XKCD standard thing. Can't your work be made as a package for Debian, Ubuntu, CentOS and Gentoo? That'd rox if it could.
Most daemons from, say, sysv, aren't really dependent on the init system.
The daemons themselves no. But the way to start them is highly dependent on the system you are running under.
They're just programs that init happens to run when it feels like it.
That's a terrible way to describe dependencies. Eg, you can't run for example NFS mounts if you don't have network, and can't do network without local FS, etc.
The daemons Ubuntu uses talk to init for some reason. If init doesn't talk back, they refuse to run. See here [osu.edu] for my specifics on it, which links to a bug report [launchpad.net] on the matter that I'm doubtful will be resolved within the foreseeable future.
Not only Ubuntu. Fedora and Gentoo does this as well. This is because they moved from a sequence based thing to an event based thing. For example, stop doing "start these daemons after syslog is started and some random delays", but do "start these daemons when the syslog socket is binding", which is the right thing to do. At some point, Debian is going to do that as well (see the huge recent init threads in the debian-devel@lists.debian.org).
So OF COURSE it wont be resolved anytime soon, because Ubuntu guys don't care, they use Upstart. Now, Bedrock doesn't address these issues, it's of very low interest to me, it's not better than managing chroot by hand, by myself.
No. Experimental is either for uploading packages which you don't want to see migrating from SID to Testing. This is useful especially at the time of freeze of testing (like right now), either for new upstream versions which includes a lot of changes (see for example yum which I uploaded recently in Experimental), or for totally new packages, or even for things which you aren't sure of the quality (eg: not fit for a release).
Well, the issue then is that testing and unstable aren't quite stable enough for me.
Unstable, I'd understand. It's there exactly for the purpose of uploading libraries and hold them for the transition period before everything goes at once in testing. But testing? How many times did you have issues with it? What issues exactly?
I can have a system which is almost entirely Debian Stable, except for the packages I want from Sid when I want them
This is what we call a backport. dget the.dsc file, dpkg-source -x that one, then build with dpkg-buidpackage. And that's if the backport doesn't exist yet in backports.debian.org. If you really don't want to do that (because there's too many new libs to depend on), then a simple chroot is enough. No need to replace everything that is already a standard in Debian (eg: no need to replace the GNU tools by busybox, grub by syslinux, etc.). But frankly, that's really not something you need to do often. Most of the time, all what you need is already there.
BTW, your example with dbus and firefox is a bit weird. Who and for what reason would you want to do this?
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...
Slashdot Mirror
Explain then why the majority of everyone is using Windows... (in other words: this is a silly question: who told you that the best tool for the job is always the one that is used?)
FreeNAS is based on FreeBSD, and boot speed (no matter what the OS) is based entirely on the hard drive speed + CPU speed + 'automagic' configuration.
This used to be truth, but it's not anymore. Look at modern init systems like upstart, OpenRC or Systemd. You'll see that these have very different results than what we could see using let's say sysv-rc. Note that there's a (huge) ongoing discussion inside Debian to choose what we will be using next (as Debian still uses the old sysv-rc thing).
Well, did we really need an "expert", to tell us that a Sokoban game is less efficient than a menu?
Doesn't make it a bad choice just because you don't like it.
That's completely right. But it's still a bad choice because ... of all the points he exposed!
That doesn't stop out of control inflation which is happening.
I can't deny it's there, everything nearly doubled in about 5 years. But this is unrelated to a lack of liquidity. That's quite the opposite in fact. There's only inflation when there's too much cash out...
In turn it doesn't stop food shortages, also happening.
What is this food shortage that everyone is talking about? Last time I checked, my local supermarket was full of food. Did you read some news about that in the "western" press? I heard nobody talking about it over here.
For the liquidity issues, you might have noticed in the last 3 weeks a large number of chinese firms suddenly dumping stocks.
I'd be happy to read about it! Please provide URLs if you have some.
One day China is going to call in the debts.
Could you explain to the readers how it is possible that a country controlling its money creation and loans directly by the central government can go into debts?
FYI, even if you are married, the visa is for 6 months, not one year anymore. After 5 years of being married AND owning a real estate property you live in AND having 200 000 yuan blocked into a bank account AND living for more than 9 months in China during this 5 years period, you may get a green card. The application currently takes more than a year. Once you get it, it's a permanent living permit that has to be renewed every 10 years. With it, you can even create a local Chinese company under your own name.
but China is having some serious liquidity issues right now
Contrary to USA, China controls money creation through the central bank (which is controlled directly by the central party). The state also controls directly all banks that are giving out loans. It also has a lot of USD in reserve. So what liquidity issues are you talking about?
Yeah, right... Like, "we're sorry, we wont steal again from everyone, we swear!" Who's going to believe this? They already crashed the world economy, stolen money by the hundreds of billions, put so many people in the streets, and doing so much fraud that it's even hard to account all of them. And all they get is "it's ok, you just have to swear not to do it again". Oh, we're safe now, thank you!
And wash trading (eg: manipulating market prices by buying and selling at the same time), and MF global scandal, and naked short sellings, and accounting fraud, and selling Silver they don't have, and...
The list goes on, and on, and on, and on. But nobody "regulates" them. Or rather, should I say, nobody does JUSTICE, and put these crooks in jail.
So, when I read that [JP Morgan is] "in favor of tougher (and substantive!) regulations", one may wonder what this means.
JP Morgan will soon go the way of Enron... They are engaged in multiple accounting fraud, and it already showed with their bad bets on Silver.
Dimon is "sorry", yet pretends that he did "good things"? WTF!!! That's a joke, right?
Perhaps he's sorry that, as one of the biggest crooks in the world, he didn't go to jail? Or maybe he's sorry about the wash trading he did, and that he got only a 30k fine, for manipulating the crude oil markets? Or probably, he is sorry for JP-Morgan naked short selling on the Silver market? Or for emitting more bonds of Silver than they physically have? Or...
Come on, we all know what these data centers are for. They are for doing high frequency trading. It's been a long time that we all know such trades are destroying more wealth than it creates.
Such declaration is simply outrageous. We're tired of the financial terrorists. None have been punished, yet destroying jobs and lives by the millions, and proves of that accumulating. This one day will stop, once the general public understands what is going on. They'd better have strong necks when that day comes, because probably, their head will go off, just like in the French revolution.
In the mean time, since the people have lost their power over this disgusting "elite", everyone should play on the same game, and buy (physical) silver coins. Not only this is a very good investment, especially considering today's record low, but this also has the side effect of crashing JP-Morgan, since (as I wrote above) they did very dangerous bets, and already lost billions. As Max Keiser puts it: "GO GO! Silver liberation army!"
Well, it works pretty well mostly. Indeed, people traveling are helping a lot are helping to have a more strongly connected web of trust, and we encourage the ones that travel to have their keys signed by those who have the most signatures (which is what I'm trying to do when I go in Debconf, considering that there's very few DDs where I live, and that they don't travel often).
However, it works less good in countries where there's no DDs at all. I can remember a case of one poor guy that wanted his key signed in Cuba, but since there was no DDs in Cuba, and that that person couldn't travel (he had no budget, and anyway, couldn't go in USA because of restrictions). It was though, because we ask for at least one PGP signature (and strongly require 2 at least, preferably from well known and very active DDs). Such cases are very difficult to handle.
But voting in person is a lot harder. PGP keys are only a way to make it possible to trust the voters. It's a technical answer to a problem. I don't see how it makes it harder to use PGP (in fact, it's harder to do without it).
It's been years that inside Debian, we vote using our PGP keys, which are in the "web of trust" (eg: signed by our peers). People got to learn about signing each other keys, then voting isn't a problem at all.
By the way, I just realize that the login form in Slashdot tells me that my password should be from 6 to 20 chars long. 6 chars at least, ok, but why is there a limit on the length? Shouldn't Slashdot use password hashing, and then don't care about the length of my password?
You probably want to contribute such functionality to the freedombox project.
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...
Yes, but it's not the default (the default is sysv-rc, and it will for Wheezy as well). So there's no way to send a bug against a package because it doesn't have a good support for systemd, which is the problem. However, I do hope that we will switch to either OpenRC or systemd for Jessie (yes, that's the name of Wheezy+1).
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?
You're missing a bit of context with that. That statement was in direct response to your request for me to explain why I singled out Ubuntu/Upstart. It was intended in contrast to how Ubuntu's/Upstart's daemons function, as sysv daemons can all run just fine in a chroot more or less irrelevant of host (provided the dependencies are met), but Ubuntu's daemons cannot (due to dependence on a specific init which the host may not use). I can go ahead and ensure Bedrock provides network before setting up NFS, but I cannot ensure Bedrock provides the specific upstart init.
You aren't answering my specific point. Ubuntu and CentOS v6 are both using Upstart. Fedora uses systemd. Gentoo uses OpenRC. If you support only sysvrc, then you're supporting only Debian...
If you are referring to automatic dependency resolution for client daemons at boot, then no, the first alpha release does not provide any means for this quite yet. It is a relatively low priority at the moment (as specifying these things manually is absolutely trivial), and the project is yet quite young.
Yes, that's what I was referring to. *NO* it's not trivial at all. The stuff from systemd is very different form initrc, and you wont succeed in having something that works just by specifying "things by hand". You really need to address the issue of events, not only the order used to start daemons.
it's not better than managing chroot by hand, by myself.
If you truly believe this, then I have almost certainly failed in properly explaining it, and I am at a loss as to where I have lead you astray. While all of this is certainly possible manually, it is significantly more work for the particular usage cases for which I utilize it.
I understand that you have integrated stuff to make it easy to use a chroot. But if you aren't addressing the system start, then why not having Bedrock as a simple package for let's say Debian, rather than having it being a full distribution, replace GNU tools by busybox (a poor choice, IMO), and all sort of things like that that we may not agree with? 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 really like your idea to be able to use apt / yum / emerge, all in one place, easily. But I don't see the point in having this inside a specific distribution. That's also, maybe, why multiple people pointed you at the XKCD standard thing. Can't your work be made as a package for Debian, Ubuntu, CentOS and Gentoo? That'd rox if it could.
This doesn't answer my question: why don't you contribute this to Debian?
Most daemons from, say, sysv, aren't really dependent on the init system.
The daemons themselves no. But the way to start them is highly dependent on the system you are running under.
They're just programs that init happens to run when it feels like it.
That's a terrible way to describe dependencies. Eg, you can't run for example NFS mounts if you don't have network, and can't do network without local FS, etc.
The daemons Ubuntu uses talk to init for some reason. If init doesn't talk back, they refuse to run. See here [osu.edu] for my specifics on it, which links to a bug report [launchpad.net] on the matter that I'm doubtful will be resolved within the foreseeable future.
Not only Ubuntu. Fedora and Gentoo does this as well. This is because they moved from a sequence based thing to an event based thing. For example, stop doing "start these daemons after syslog is started and some random delays", but do "start these daemons when the syslog socket is binding", which is the right thing to do. At some point, Debian is going to do that as well (see the huge recent init threads in the debian-devel@lists.debian.org).
So OF COURSE it wont be resolved anytime soon, because Ubuntu guys don't care, they use Upstart. Now, Bedrock doesn't address these issues, it's of very low interest to me, it's not better than managing chroot by hand, by myself.
No. Experimental is either for uploading packages which you don't want to see migrating from SID to Testing. This is useful especially at the time of freeze of testing (like right now), either for new upstream versions which includes a lot of changes (see for example yum which I uploaded recently in Experimental), or for totally new packages, or even for things which you aren't sure of the quality (eg: not fit for a release).
You don't need to reply to absolutely all posts, do you know? :)
Well, the issue then is that testing and unstable aren't quite stable enough for me.
Unstable, I'd understand. It's there exactly for the purpose of uploading libraries and hold them for the transition period before everything goes at once in testing. But testing? How many times did you have issues with it? What issues exactly?
I can have a system which is almost entirely Debian Stable, except for the packages I want from Sid when I want them
This is what we call a backport. dget the .dsc file, dpkg-source -x that one, then build with dpkg-buidpackage. And that's if the backport doesn't exist yet in backports.debian.org. If you really don't want to do that (because there's too many new libs to depend on), then a simple chroot is enough. No need to replace everything that is already a standard in Debian (eg: no need to replace the GNU tools by busybox, grub by syslinux, etc.). But frankly, that's really not something you need to do often. Most of the time, all what you need is already there.
BTW, your example with dbus and firefox is a bit weird. Who and for what reason would you want to do this?
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...