Actually, according to Dr. Drake, the inventor of the Drake Equation, founder of SETI, Earth is becoming less visible all the time. The satellites you talk about aren't pointed out into space, they are pointed towards Earth. We have also switched from analog to digital transmissions, so essentially everything we're transmitting at this point is indistinguishable from noise. Broadcasting large amounts of energy into the universe in analog is not something that we can expect other civilizations to do for a very long time, if our own civilization is any guide. Not only that, but the Sun also produces a fair amount of radio-frequency radiation, so there's a pretty high noise floor. Even when we're trying to talk to Mars, the SNR is miserable.
The odds against detecting extraterrestrial transmissions, or extraterrestrials detecting us, are so insurmountably vast as to defy description. I think that Dr. Drake should accept the logical conclusions of his statements and end the SETI project. We have met the Great Filter and he is us.
I've just read the source of the Linux/BSD sysvinit package. Unless I am reading it wrong, it uses a simple for loop to iterate through the inittab entries. This is sequential and not parallel.
SysV init replacements are a superset of init's features, so the use cases are broadly the same, however the environment has changed quite a bit: hotplugging of various devices is far more common, changing networks, and so on. We're also seeing a rise in containerized applications and virtualization. Computer systems are becoming very complex, so we must decide where that complexity should be located. The obvious choice for this type of task is to abstract the common functionality into a shared library. There is not really any way to do that and keep init small: the complexity must exist somewhere, and it makes no sense to have init exist simply to kick off the "real" service manager.
So the question is not really "what use cases are there?", but "what should init do?", and again, the consensus for the last couple decades is to move functionality from scripts to the service manager, instead of relying on each and every script to do things correctly. The most basic task seems to be dependency resolution: it's simpler to add markup to a script that tells the manager what it needs than to write dozens of lines of code trying to figure out if ServiceA and InterfaceB are up. Starting services in parallel is another obvious improvement. Socket activation is also beneficial.
Init/inittab was intentionally simple. It will start processes for you -- unless they have dependencies. It will restart processes for you -- blindly, and it will block any other tasks while it does so. I'd be willing to bet most of the SysV init scripts written re-implement some feature that inittab provides. Frankly I don't know why you would try to argue that 7k lines of code ought to be good enough for anyone.
The subject of the post is not always the topic of the article. It's often a tangential or unrelated matter. I usually change the subject line of a thread when posting, not because I expect anyone to read it, but so I'll have a better idea what is being responded to if I get any reply notifications in my email.
Just because you don't use something does not make it stupid.
Use the D1 discussion system. It still works just fine, and it has both a dropdown and a "confirm" button. Find it in your account options under 'Discussion'.
"SJW" functions similarly to "liberal" and other pejoratives. It indicates a tribal allegiance on the part of the speaker: a sort of shibboleth. It means, "someone I don't identify with and have ascribed various bad qualities to."
I have a vague sympathy for people who rail against perceived liberal social trends. I believe that it's about as effective as arguing with an advancing glacier, but it's not irrational to fear change. However, I can think of no surer sign that someone has discarded reason than the use of pejoratives against one's political enemies. You are no longer arguing against a man or against a rational position, you're arguing against a figment of your imagination. Denying your opponents their measure of common humanity also deeply undermines any moral argument at hand.
In short, pejoratives such as "SJW", "liberal", "hipster", and "millennial" mean: the writer's opinions are not worth the time taken to read them.
Wine works pretty well these days, unless you're trying to run the latest and greatest games. But it's best to isolate these things; you may run into a situation where due to conflicting requirements, your wine installations get just as FUBAR'd as that Ubuntu install. I would recommend using PlayOnLinux: it provides a nice way to manage wine versions and wineprefixes, and often times it has scripts to set up the application you want to run.
I'm thinking about giving ReactOS a try in a VM. I'm not in a hurry to let alpha-quality software touch bare metal, though.
To pick a nit, the medallion market is a government run monopoly, but the taxi market is not. Some sort of medallion system is necessary; the system will only begin to self-correct for traffic congestion at the point where it becomes uneconomical to sit in traffic. If your fare is paying per minute as well as per mile, this may never happen, and even if that is not the case, an idling car uses very little gasoline.
The situation in Panama City is the end-game for Uber. Anyone can drive a taxi, for a modest license fee. The fares are very low and taxicabs are plentiful. So how do you make money? You skimp on maintenance and insurance, jack up your prices for anyone you don't like, and if the person wants to go somewhere congested, either charge them and only take them a couple blocks, or just refuse service entirely. Also, because of the iron laws of competition, the price of the service is going to be driven down to the lowest amount that will keep the car and driver on the road. If you want to introduce this to America, keep in mind that it's not going to be Uber's fault if their drivers don't make minimum wage and congestion goes wild.
It doesn't matter if it happened in Belize, this is the sort of thing the FBI does for American citizens where ever they are.
Is there a number that I should call to arrange that?
That it happened in Belize is actually rather telling, and if you had spent any long time between, say, Mexico and Panama, you might have a different perspective on this. Government power is one or more of [a] arbitrary, [b] weak, and [c] for purchase. The drug trade supports healthy levels of gang activity all along the coast, and Belize is no exception -- far from it. I cannot begin to describe to you the level of corruption that exists in these countries, but suffice to say that the local criminal element is frequently stronger than the government.
It's pretty rare for an argument with a neighbor to result in murder. Arguments with drug lords, on the other hand...
SR rests on two postulates: first, that the speed of light is invariant, and secondly that the laws of physics are the same in all reference frames. Which do you take issue with?
Light does not need a medium to propagate through. Calling empty space "ether" just means you don't understand the issue. If we have a catastrophic vacuum decay light will still be transmitted. Einstein described the geometry of the universe; it's not that light travels at c, it's that everything is traveling at c and massless effects have zero velocity in the time dimension.
If you think otherwise, please explain how these results match the theory exactly. If your pet theory can explain that, provide an additional test which shows that your theory has greater predictive power. Until you can do the first, you're a simple crank, and until you can do the latter, you're on the wrong side of Occam's Razor.
Before we go further down this rabbit hole, do you mind explaining "init's parallel nature"? Most of the replacements for SysV init have used a parallel/asynchronous startup, but I was not aware that was any part of the original capabilities.
They would have seen gravitational waves as transient noise, in the same respect that passing vehicles and persons represented noise sources, and of far lesser magnitude. Without a physical framework suggesting that this noise was meaningful, there would have been no reason to suspect it was. Yes, they were intelligent fellows, but as far as I know, neither understood their experiments to mean that the aether did not exist, and continued to conduct experiments on the matter. I don't want to say exactly that they wouldn't have believed in gravitational waves if their hair was on fire due to that, but certainly in their famed experiment [a] they weren't looking for that, [b] it would have disturbed the thing they were looking for, and [c] they were not disposed to believe it even if they had found it. They were eminent and respectable scientists, their experiment was correct and well-founded, and they were dead wrong and no degree of accuracy could have changed that.
No, they are identical in the type of instrument they used, not in what they were trying to measure. MM were trying to find a "preferred frame", to see if the speed of light varied with the orientation (and motion around the sun) of the detector. They would not have found that no matter what the qualities of their detector were because it does not exist, and if they had detected gravitational waves, they would have been considered noise for the purpose of that experiment. You're saying that two different uses of an interferometer constitute the same experiment. You are very much mistaken.
They weren't going to find gravity waves because they weren't looking for gravity waves. Gravity waves would have been considered noise in their experiment, even if they had an arbitrarily precise machine, because that was not the thing they were trying to measure. That was the whole point of having a rotating interferometer. They were trying to detect a "preferred frame", and they would not have detected one no matter how precise their machine was because there is no such animal.
No, the MM experiment was measuring the speed of light in different orientations. Just because both used interferometers does not mean that they are measuring the same thing. If the MM experiment were arbitrarily more precise they would not have detected any change in the speed of light regardless of the orientation of their device, and spacetime fluctuations would have been dismissed as noise, and not particularly significant noise at that.
You are deeply confused about pre-Einsteinian theories of light and the purpose and significance of the MM experiment.
It's very difficult to reason about the universe without causality. Personally, I would rather not go there, the possible delights of science fiction notwithstanding.
It's not just systemd that is destroying SysV. It's also Solaris, OS X, PC-BSD, and FreeBSD -- we can probably say well over 90% of the major Unix platforms. For better or worse, OpenRC is also making many of the same choices as systemd, including heavy dependence on C libraries, dependency resolution, parallel startup, and cgroup support. The critical failure of SysV init is the pidfile. It was always a bad hack — perhaps necessary for cross-platform support in a world without real process tracking, but now there isn't a hell of a lot of competition in any given market segment, and cross-platform support is being seen as less important than being able to accurately manage services. Yes, pidfiles almost always match the service they are supposed to, but this is not something that should ever have been left to userland. Similarly, daemonizing a process should never have been left up to script writers, given that glibc doesn't even do it correctly.
So now we're putting process tracking back into the kernel and it's a breaking change. If cgroups had been part of the POSIX standard years ago, systemd would have attracted no more attention than upstart when it was released. It *is* init, it has a superset of the same features, only with an event-driven model, and a slightly more sensible approach to dependency resolution than upstart. You may not have reached the limits of inittab, but other people with different use-cases have, and there's nothing in particular wrong with either case. The argument with systemd isn't an argument about how best to manage services, it's about technical debt so entrenched that people think that's the way it's supposed to be.
There are limits to how much you can miniaturize a nuclear weapon. The term "critical mass" is key: you need a certain amount of fissionable material in order to sustain the chain reaction. This varies for different isotopes, and can be influenced by the level of explosive compression that you are able to achieve. This paper puts a lower bound for U235 and Pu at 6.5kg and 2kg respectively and discusses some of the compression methods. The smallest warhead made (W54) weighed about 23kg.
Apologies, I had thought that the links were sufficiently informative, especially given that we had an article on the same subject earlier this week. I've never used Docker personally, and have a fairly loose grasp of what it entails, but the idea of application containers has been around for something like 20 years -- BSD Jails, lxc, systemd-nspawn, Solaris zones, and whatever that CoreBoot based one is -- there was an article about it on Thursday. Half of the comments are saying how Docker is a dressed-up version of an old solved problem. With respect, I think this one is on you, although your point in general stands.
This is not Star Trek. We do not have reactionless drives and unless there's a wild loophole in thermodynamics, we likely will. You are always going to be held back by the rocket equation.
A Ship with a multi mega watt power source
Ludicrous. Why would you even want to try to dissipate that much heat?
A Ship with several smaller vehicles for going to and from a planet
This is not Star Trek. There isn't going to be a one-size-fits-all solution for descending a gravity well. Hence why Curiosity's descent was so complicated -- and again, you run up against the rocket equation.
I had rather thought that was the way things worked now. Slashdot users aren't generally great about submitting high quality articles. I've only submitted a couple in my entire history. If there were some incentive to bring good content to the table, now....
With regards to open sourcing Slashdot, I am not that completely opening the code would be best, and I do think that it would be a hard sell to C-levels. That said, some recent version of the code needs to be open, and development should be community-driven. The Unicode thing should have been a bug report/feature request. GitHub would be the obvious choice -- aside from a little issue with +1 spam, their issue/feature tracker integration is rather nice. I promise that ad-revenue-driven feature requests will receive mature consideration. For realio.
I mostly use the exact setup you're talking about. I can't really speak to the "teamwork" aspects; for that I generally use CollabEdit, which is simpler for one-off collaboration. I got a Chromebook because I was planning on being in fairly impoverished areas in Central America for months or years, and I wanted a laptop that I was not going to worry about breaking. It works pretty well, all things considered. It's relatively simple to install a 'real' linux distro via crouton and get access to all the normal linux goodies. One specific advantage to ChromeOS is that it keeps track of what apps you have installed, and if you ever have to replace the unit, you can just sit at the new one, type your login info, and in about two minutes the new machine will have exactly the same stuff the old one did.
Having your development tools/files in the cloud means that they are inaccessible to you without an Internet connection, however, you don't need much of a net connection to be able to work: for Cloud9 there's an initial download of I believe about 1 MB for the editor, and actually editing code is possible down to a hundred bytes per second. Creating a local repo from a GitHub or Bitbucket repository is very simple, and each coding workspace gets its own little virtual machine, so you can install gems, run tests, and do anything you'd normally do. It also saves process state, so you can start (e.g.) pry, fool around with the interpreter, close the window, and the next time you start, pry will still be running. It actually saves quite a few brain cycles: you have less effort to figure out what you were doing the last time. Code completion and refactoring support exists, but is not what you would call world-class, more like SublimeEdit than intellij.
I have been using cloud9, but I have shopped around for various online editors at times, and so far I have not found any particularly compelling reasons to switch. I do not miss setting up a new chroot or container for a new project, or worrying about syncing code between workstations. Also note that there are online IDEs which can be run on your own private server (Cloud9 among them), for a hybrid approach, and of course there's nothing wrong with emacs over ssh if it comes down to it. At this point I doubt I would go back to a "real" IDE unless required to by an employer.
"Security in itself is useless. The upside is always somewhere else. The security is never the thing that you really care about."
Which is not to say that it's insecure; given that it runs on more devices than any other OS, any exploits would be huge. I'm not really sure how Windows security measures up these days, but I get the impression that the typical Windows install has a greater amount of exposed moving parts.
Slashdot Mirror
Actually, according to Dr. Drake, the inventor of the Drake Equation, founder of SETI, Earth is becoming less visible all the time. The satellites you talk about aren't pointed out into space, they are pointed towards Earth. We have also switched from analog to digital transmissions, so essentially everything we're transmitting at this point is indistinguishable from noise. Broadcasting large amounts of energy into the universe in analog is not something that we can expect other civilizations to do for a very long time, if our own civilization is any guide. Not only that, but the Sun also produces a fair amount of radio-frequency radiation, so there's a pretty high noise floor. Even when we're trying to talk to Mars, the SNR is miserable.
The odds against detecting extraterrestrial transmissions, or extraterrestrials detecting us, are so insurmountably vast as to defy description. I think that Dr. Drake should accept the logical conclusions of his statements and end the SETI project. We have met the Great Filter and he is us.
I've just read the source of the Linux/BSD sysvinit package. Unless I am reading it wrong, it uses a simple for loop to iterate through the inittab entries. This is sequential and not parallel.
SysV init replacements are a superset of init's features, so the use cases are broadly the same, however the environment has changed quite a bit: hotplugging of various devices is far more common, changing networks, and so on. We're also seeing a rise in containerized applications and virtualization. Computer systems are becoming very complex, so we must decide where that complexity should be located. The obvious choice for this type of task is to abstract the common functionality into a shared library. There is not really any way to do that and keep init small: the complexity must exist somewhere, and it makes no sense to have init exist simply to kick off the "real" service manager.
So the question is not really "what use cases are there?", but "what should init do?", and again, the consensus for the last couple decades is to move functionality from scripts to the service manager, instead of relying on each and every script to do things correctly. The most basic task seems to be dependency resolution: it's simpler to add markup to a script that tells the manager what it needs than to write dozens of lines of code trying to figure out if ServiceA and InterfaceB are up. Starting services in parallel is another obvious improvement. Socket activation is also beneficial.
Init/inittab was intentionally simple. It will start processes for you -- unless they have dependencies. It will restart processes for you -- blindly, and it will block any other tasks while it does so. I'd be willing to bet most of the SysV init scripts written re-implement some feature that inittab provides. Frankly I don't know why you would try to argue that 7k lines of code ought to be good enough for anyone.
The subject of the post is not always the topic of the article. It's often a tangential or unrelated matter. I usually change the subject line of a thread when posting, not because I expect anyone to read it, but so I'll have a better idea what is being responded to if I get any reply notifications in my email.
Just because you don't use something does not make it stupid.
Use the D1 discussion system. It still works just fine, and it has both a dropdown and a "confirm" button. Find it in your account options under 'Discussion'.
"SJW" functions similarly to "liberal" and other pejoratives. It indicates a tribal allegiance on the part of the speaker: a sort of shibboleth. It means, "someone I don't identify with and have ascribed various bad qualities to."
I have a vague sympathy for people who rail against perceived liberal social trends. I believe that it's about as effective as arguing with an advancing glacier, but it's not irrational to fear change. However, I can think of no surer sign that someone has discarded reason than the use of pejoratives against one's political enemies. You are no longer arguing against a man or against a rational position, you're arguing against a figment of your imagination. Denying your opponents their measure of common humanity also deeply undermines any moral argument at hand.
In short, pejoratives such as "SJW", "liberal", "hipster", and "millennial" mean: the writer's opinions are not worth the time taken to read them.
Wine works pretty well these days, unless you're trying to run the latest and greatest games. But it's best to isolate these things; you may run into a situation where due to conflicting requirements, your wine installations get just as FUBAR'd as that Ubuntu install. I would recommend using PlayOnLinux: it provides a nice way to manage wine versions and wineprefixes, and often times it has scripts to set up the application you want to run.
I'm thinking about giving ReactOS a try in a VM. I'm not in a hurry to let alpha-quality software touch bare metal, though.
To pick a nit, the medallion market is a government run monopoly, but the taxi market is not. Some sort of medallion system is necessary; the system will only begin to self-correct for traffic congestion at the point where it becomes uneconomical to sit in traffic. If your fare is paying per minute as well as per mile, this may never happen, and even if that is not the case, an idling car uses very little gasoline.
The situation in Panama City is the end-game for Uber. Anyone can drive a taxi, for a modest license fee. The fares are very low and taxicabs are plentiful. So how do you make money? You skimp on maintenance and insurance, jack up your prices for anyone you don't like, and if the person wants to go somewhere congested, either charge them and only take them a couple blocks, or just refuse service entirely. Also, because of the iron laws of competition, the price of the service is going to be driven down to the lowest amount that will keep the car and driver on the road. If you want to introduce this to America, keep in mind that it's not going to be Uber's fault if their drivers don't make minimum wage and congestion goes wild.
Fair enough. I stand corrected.
It doesn't matter if it happened in Belize, this is the sort of thing the FBI does for American citizens where ever they are.
Is there a number that I should call to arrange that?
That it happened in Belize is actually rather telling, and if you had spent any long time between, say, Mexico and Panama, you might have a different perspective on this. Government power is one or more of [a] arbitrary, [b] weak, and [c] for purchase. The drug trade supports healthy levels of gang activity all along the coast, and Belize is no exception -- far from it. I cannot begin to describe to you the level of corruption that exists in these countries, but suffice to say that the local criminal element is frequently stronger than the government.
It's pretty rare for an argument with a neighbor to result in murder. Arguments with drug lords, on the other hand...
SR rests on two postulates: first, that the speed of light is invariant, and secondly that the laws of physics are the same in all reference frames. Which do you take issue with?
Light does not need a medium to propagate through. Calling empty space "ether" just means you don't understand the issue. If we have a catastrophic vacuum decay light will still be transmitted. Einstein described the geometry of the universe; it's not that light travels at c, it's that everything is traveling at c and massless effects have zero velocity in the time dimension.
If you think otherwise, please explain how these results match the theory exactly. If your pet theory can explain that, provide an additional test which shows that your theory has greater predictive power. Until you can do the first, you're a simple crank, and until you can do the latter, you're on the wrong side of Occam's Razor.
Before we go further down this rabbit hole, do you mind explaining "init's parallel nature"? Most of the replacements for SysV init have used a parallel/asynchronous startup, but I was not aware that was any part of the original capabilities.
They would have seen gravitational waves as transient noise, in the same respect that passing vehicles and persons represented noise sources, and of far lesser magnitude. Without a physical framework suggesting that this noise was meaningful, there would have been no reason to suspect it was. Yes, they were intelligent fellows, but as far as I know, neither understood their experiments to mean that the aether did not exist, and continued to conduct experiments on the matter. I don't want to say exactly that they wouldn't have believed in gravitational waves if their hair was on fire due to that, but certainly in their famed experiment [a] they weren't looking for that, [b] it would have disturbed the thing they were looking for, and [c] they were not disposed to believe it even if they had found it. They were eminent and respectable scientists, their experiment was correct and well-founded, and they were dead wrong and no degree of accuracy could have changed that.
Ether theory had huge issues even before the experiment. There are probably better examples of unexpected discoveries.
No, they are identical in the type of instrument they used, not in what they were trying to measure. MM were trying to find a "preferred frame", to see if the speed of light varied with the orientation (and motion around the sun) of the detector. They would not have found that no matter what the qualities of their detector were because it does not exist, and if they had detected gravitational waves, they would have been considered noise for the purpose of that experiment. You're saying that two different uses of an interferometer constitute the same experiment. You are very much mistaken.
They weren't going to find gravity waves because they weren't looking for gravity waves. Gravity waves would have been considered noise in their experiment, even if they had an arbitrarily precise machine, because that was not the thing they were trying to measure. That was the whole point of having a rotating interferometer. They were trying to detect a "preferred frame", and they would not have detected one no matter how precise their machine was because there is no such animal.
No, the MM experiment was measuring the speed of light in different orientations. Just because both used interferometers does not mean that they are measuring the same thing. If the MM experiment were arbitrarily more precise they would not have detected any change in the speed of light regardless of the orientation of their device, and spacetime fluctuations would have been dismissed as noise, and not particularly significant noise at that.
You are deeply confused about pre-Einsteinian theories of light and the purpose and significance of the MM experiment.
It's very difficult to reason about the universe without causality. Personally, I would rather not go there, the possible delights of science fiction notwithstanding.
It's not just systemd that is destroying SysV. It's also Solaris, OS X, PC-BSD, and FreeBSD -- we can probably say well over 90% of the major Unix platforms. For better or worse, OpenRC is also making many of the same choices as systemd, including heavy dependence on C libraries, dependency resolution, parallel startup, and cgroup support. The critical failure of SysV init is the pidfile. It was always a bad hack — perhaps necessary for cross-platform support in a world without real process tracking, but now there isn't a hell of a lot of competition in any given market segment, and cross-platform support is being seen as less important than being able to accurately manage services. Yes, pidfiles almost always match the service they are supposed to, but this is not something that should ever have been left to userland. Similarly, daemonizing a process should never have been left up to script writers, given that glibc doesn't even do it correctly.
So now we're putting process tracking back into the kernel and it's a breaking change. If cgroups had been part of the POSIX standard years ago, systemd would have attracted no more attention than upstart when it was released. It *is* init, it has a superset of the same features, only with an event-driven model, and a slightly more sensible approach to dependency resolution than upstart. You may not have reached the limits of inittab, but other people with different use-cases have, and there's nothing in particular wrong with either case. The argument with systemd isn't an argument about how best to manage services, it's about technical debt so entrenched that people think that's the way it's supposed to be.
There are limits to how much you can miniaturize a nuclear weapon. The term "critical mass" is key: you need a certain amount of fissionable material in order to sustain the chain reaction. This varies for different isotopes, and can be influenced by the level of explosive compression that you are able to achieve. This paper puts a lower bound for U235 and Pu at 6.5kg and 2kg respectively and discusses some of the compression methods. The smallest warhead made (W54) weighed about 23kg.
Apologies, I had thought that the links were sufficiently informative, especially given that we had an article on the same subject earlier this week. I've never used Docker personally, and have a fairly loose grasp of what it entails, but the idea of application containers has been around for something like 20 years -- BSD Jails, lxc, systemd-nspawn, Solaris zones, and whatever that CoreBoot based one is -- there was an article about it on Thursday. Half of the comments are saying how Docker is a dressed-up version of an old solved problem. With respect, I think this one is on you, although your point in general stands.
A Ship that you can point in a direction and go.
This is not Star Trek. We do not have reactionless drives and unless there's a wild loophole in thermodynamics, we likely will. You are always going to be held back by the rocket equation.
A Ship with a multi mega watt power source
Ludicrous. Why would you even want to try to dissipate that much heat?
A Ship with several smaller vehicles for going to and from a planet
This is not Star Trek. There isn't going to be a one-size-fits-all solution for descending a gravity well. Hence why Curiosity's descent was so complicated -- and again, you run up against the rocket equation.
I had rather thought that was the way things worked now. Slashdot users aren't generally great about submitting high quality articles. I've only submitted a couple in my entire history. If there were some incentive to bring good content to the table, now....
With regards to open sourcing Slashdot, I am not that completely opening the code would be best, and I do think that it would be a hard sell to C-levels. That said, some recent version of the code needs to be open, and development should be community-driven. The Unicode thing should have been a bug report/feature request. GitHub would be the obvious choice -- aside from a little issue with +1 spam, their issue/feature tracker integration is rather nice. I promise that ad-revenue-driven feature requests will receive mature consideration. For realio.
I mostly use the exact setup you're talking about. I can't really speak to the "teamwork" aspects; for that I generally use CollabEdit, which is simpler for one-off collaboration. I got a Chromebook because I was planning on being in fairly impoverished areas in Central America for months or years, and I wanted a laptop that I was not going to worry about breaking. It works pretty well, all things considered. It's relatively simple to install a 'real' linux distro via crouton and get access to all the normal linux goodies. One specific advantage to ChromeOS is that it keeps track of what apps you have installed, and if you ever have to replace the unit, you can just sit at the new one, type your login info, and in about two minutes the new machine will have exactly the same stuff the old one did.
Having your development tools/files in the cloud means that they are inaccessible to you without an Internet connection, however, you don't need much of a net connection to be able to work: for Cloud9 there's an initial download of I believe about 1 MB for the editor, and actually editing code is possible down to a hundred bytes per second. Creating a local repo from a GitHub or Bitbucket repository is very simple, and each coding workspace gets its own little virtual machine, so you can install gems, run tests, and do anything you'd normally do. It also saves process state, so you can start (e.g.) pry, fool around with the interpreter, close the window, and the next time you start, pry will still be running. It actually saves quite a few brain cycles: you have less effort to figure out what you were doing the last time. Code completion and refactoring support exists, but is not what you would call world-class, more like SublimeEdit than intellij.
I have been using cloud9, but I have shopped around for various online editors at times, and so far I have not found any particularly compelling reasons to switch. I do not miss setting up a new chroot or container for a new project, or worrying about syncing code between workstations. Also note that there are online IDEs which can be run on your own private server (Cloud9 among them), for a hybrid approach, and of course there's nothing wrong with emacs over ssh if it comes down to it. At this point I doubt I would go back to a "real" IDE unless required to by an employer.
Linus did say that security is not the end-all be-all of Linux.
"Security in itself is useless. The upside is always somewhere else. The security is never the thing that you really care about."
Which is not to say that it's insecure; given that it runs on more devices than any other OS, any exploits would be huge. I'm not really sure how Windows security measures up these days, but I get the impression that the typical Windows install has a greater amount of exposed moving parts.