You can find a full smart phone for $30 in the United States as well. But not everyone wants or needs a full smartphone (see: parents, elderly). Or they care more about battery life than features.
Considering the proliferation of programming languages out there, holding a spot in the top ten is respectable. Certainly not tantamount to self-mutilation.
It may not be the most popular option, but Ruby is hardly a marginal language. RedMonk has it tied for 6th with C++, PYPL has it at 10th, and TIOBE has it at 14th. It came off from the Rails high, but it remains steadily popular.
The ecosystem has actually got significantly better over the years, especially as Puppet, Chef, MCollective and others have driven popularity as an admin language, rather than a web language. But more importantly, JRuby pulls in the entire Java ecosystem, which actually puts it in a better position than perl or python, in my opinion. There is Jython, but that lags significantly behind C Python (current stable is 2.5 compatible, which was released eight years ago; their 2.7 release has been in beta for about 21 months) while JRuby offers Ruby 2.1 compatibility in their current stable release and will be putting out their release candidate for 2.2 around the same time as the Ruby 2.2 stable release.
The real win for me is JRuby. The Java ecosystem is at least as broad as perl, and generally better suited to enterprise applications. There are generally perl modules for everything, but they often perform far worse (e.g. Net::LDAP is probably an order of magnitude slower than UnboundID processing LDIF) or are just terrible code (e.g. Net::Sieve::Script which is a regex-based hack, rather than an actual language parser like jSieve).
2) Um, no. Objects cannot magically change their class, period. You might assign a different object to a given variable, but the language is strongly typed.
3) Huh? There are relatively few symbols in Ruby, as a rule. Are you referring to special variables (like $: $0 etc?)? Those are ancillary and not considered idiomatic these days. Don't like them? Don't use them.
4) Why shouldn't they? The first is a just a chained method. No different than "foo.split(' ').length;" in Java. I'm assuming the latter is supposed to be "num.to_s 16", which would be "Integer.toString(num,16)" in Java, but that is just because the Java designers weren't nice enough to allow you to pass a radix argument to the non-static method. There is nothing in the language that would have precluded "num.toString(16);" being valid.
If you want to know the impetus behind systemd, why not go to source. Lennart lays out the problems he was trying to solve and the design process on his blog. Specifically, the intro post and biggest myths rundown would a solid positive case for the approach and technology.
Don't know, don't care. The case against notability was stronger when it was first submitted, likely, but it is certainly hard to defend now. There are mature bindings for most languages, it underpins a number of higher level data stores (including OpenLDAP, of course, but also FineDB, Hustle), and is a supported back-end for a large number of projects (sometimes as a default component, as with CFengine and Zimbra).
If the rules legitimately preclude a page on LMDB, they certainly should preclude individual pages for MySQL backends like Falcon, Aria, and Toku, shouldn't it? And yet there they are.
No, that's exactly what I read into the suits. Dealing with a deadly, incurable disease demands an excess of caution, even if the transmission rate is dramatically lower than other diseases. You don't need each patient to infect a hundred other people for it to spread; so long as it is more than one, it is a growing problem.
The risk here isn't because the disease is especially contagious; it is because the containment and treatment is especially costly. Doctor diagnoses someone with the flu, they send them home and tell them to drink plenty of wayer and get plenty of rest. In an extreme case, they may push IV fluids and keep a few days for observation.
With Ebola that becomes weeks of quarantine and treatment, stringent sterilization procedures, and monitoring anyone they've come in contact with. It wouldn't take an especially large outbreak to strain and ultimately exhaust available resources. And as necessity forces compromises in care and treatment by untrained individuals, transmission rates will spike.
Really not a viable treatment course. Even with monitoring and proactive care, your chances of survival are about even. In isolation, pretty much a death sentence.
Coughing and sneezing may be symptoms of specific diseases, but they are also reflexes that are not necessarily linked to a specific disease. People may cough because they aspirated saliva, or because they just came in from smoking. People may sneeze because its ragweed season, of because of the judiciously applied perfume of the person next to them (or the guy who just came in from smoking), or even as a reaction to a brightly lit waiting room.
Possibly a bigger risk than the waiting room itself would be the bathrooms. The likelihood of contamination when there is evacuation of infectious material, as well as repeated bare skin contact with the same surface by a stream of individuals strikes me as very high, especially if some patients wait long enough that they have developed rashes.
In iso+lation, this is a solvable problem, but if a critical mass of patients develops, it can quickly get out of hand. Especially now, as we are enter flu season.
Separation is not enough when the virus can survive outside the body for extended periods. All it takes is for one infected individual to rest their sweaty hands on an armrest and that seat becomes a possible vector. There is a reason people are wearing those suits, and it is not because they look cool.
Sending people with sick kids is not a particularly viable long term solution. Even if it reduces the immediate risk to the general population, it puts the rest of their family at grave risk and is a likely death sentence for the child. Homes are simply not equipped to deliver the necessary palliative care needed by patients, nor are most people trained in the necessary sanitation procedures to prevent transmission.
People with fevers sweat, they cough, they sneeze. Droplet transmission is a serious threat, especially in cramped conditions. No licking necessary. But then you throw children in the mix, and there will be licking and mouthing of potentially contaminated items. And sick kids that want to be held by mommy or daddy, and will sneeze directly in their face.
Not saying that we have reason to panic now, but it is fatuous to dismiss the very real challenges of effective containment once the disease becomes endemic to a particular population.
Java is going nowhere. In addition to being in most phones (Android, Jave ME), it is in every Blu-Ray player (BD-J), every cable box (OCAP), cash registers, ATMs and voting machines. And that isn't even touching on enterprise, web and desktop applications.
Take a look at most language rankings and Java remains near or at the top, whether you look at Tiobe, PyPL, RedMonk, IEEE Spectrum, or the various job surveys published by the likes of Dice.com and eWeek.
Java has a vast ecosystem, excellent threading and concurrency support, robust monitoring and debugging tools, and can rival (or exceed) the performance of traditional compiled languages.
This is true for both small scale and large scale problems. For example, I wrote a little tool to do LDIF transforms in perl. Six hours later, it wasn't even half finished. Rewrote it using a Java library (UnboundSDK) and it finished in about twenty-five minutes.
On the other end of spectrum, I wrote a load-testing application that scaled cleanly to tens of thousands of threads. In a couple of hours. With no experience writing anything to that scale before.
(And the idea that Java is strictly Android these days is absurd. Your cable box runs Java. So does your blu-ray player. Along with ATMs, cash registers, voting machines, any number of enterprise applications, webservices, etc, etc. It is an incredibly pervasive language.)
It also turns out you can implement everything in plain Java libraries. In fact it is a heck of a lot easier, since you don't need to wrap the C modules; everything Just Works.
How big a stack do you need to match a 1320 tape library? Even using 4TB disks you're talking 825 disks, which means 51 enclosures. And then four racks to hold those enclosures. And enough floor space to hold those racks. And enough circuits to power those racks.
At that level of scale, tape is simply a better option for archival storage.
Eh? Both T-Mobile and AT&T (and Verizon, actually) offer no-contract service. Not one or two year. No year. Now you might finance a phone through them, and be on the hook for paying that, but that is not the same thing as being under a service contract.
Slashdot Mirror
Know what systemd was heavily inspired by? The MacOS X init, launchd.
You can find a full smart phone for $30 in the United States as well. But not everyone wants or needs a full smartphone (see: parents, elderly). Or they care more about battery life than features.
No one?
ahref=https://twitter.com/jruby/status/534471839620165632rel=url2html-15138https://twitter.com/jruby/stat...>
Considering the proliferation of programming languages out there, holding a spot in the top ten is respectable. Certainly not tantamount to self-mutilation.
It may not be the most popular option, but Ruby is hardly a marginal language. RedMonk has it tied for 6th with C++, PYPL has it at 10th, and TIOBE has it at 14th. It came off from the Rails high, but it remains steadily popular.
The ecosystem has actually got significantly better over the years, especially as Puppet, Chef, MCollective and others have driven popularity as an admin language, rather than a web language. But more importantly, JRuby pulls in the entire Java ecosystem, which actually puts it in a better position than perl or python, in my opinion. There is Jython, but that lags significantly behind C Python (current stable is 2.5 compatible, which was released eight years ago; their 2.7 release has been in beta for about 21 months) while JRuby offers Ruby 2.1 compatibility in their current stable release and will be putting out their release candidate for 2.2 around the same time as the Ruby 2.2 stable release.
The real win for me is JRuby. The Java ecosystem is at least as broad as perl, and generally better suited to enterprise applications. There are generally perl modules for everything, but they often perform far worse (e.g. Net::LDAP is probably an order of magnitude slower than UnboundID processing LDIF) or are just terrible code (e.g. Net::Sieve::Script which is a regex-based hack, rather than an actual language parser like jSieve).
1) anyObject.class
2) Um, no. Objects cannot magically change their class, period. You might assign a different object to a given variable, but the language is strongly typed.
3) Huh? There are relatively few symbols in Ruby, as a rule. Are you referring to special variables (like $: $0 etc?)? Those are ancillary and not considered idiomatic these days. Don't like them? Don't use them.
4) Why shouldn't they? The first is a just a chained method. No different than "foo.split(' ').length;" in Java. I'm assuming the latter is supposed to be "num.to_s 16", which would be "Integer.toString(num,16)" in Java, but that is just because the Java designers weren't nice enough to allow you to pass a radix argument to the non-static method. There is nothing in the language that would have precluded "num.toString(16);" being valid.
Java is grand. Using jRuby to prototype, explore and extend is even better.
Looks far more like a smarter version of Sonos, at the same price point.
If you want to know the impetus behind systemd, why not go to source. Lennart lays out the problems he was trying to solve and the design process on his blog. Specifically, the intro post and biggest myths rundown would a solid positive case for the approach and technology.
Don't know, don't care. The case against notability was stronger when it was first submitted, likely, but it is certainly hard to defend now. There are mature bindings for most languages, it underpins a number of higher level data stores (including OpenLDAP, of course, but also FineDB, Hustle), and is a supported back-end for a large number of projects (sometimes as a default component, as with CFengine and Zimbra).
If the rules legitimately preclude a page on LMDB, they certainly should preclude individual pages for MySQL backends like Falcon, Aria, and Toku, shouldn't it? And yet there they are.
LMDB was deleted from Wikipedia, not Python-LMDB.
The bindings are not especially notable. The embedded database is.
No, that's exactly what I read into the suits. Dealing with a deadly, incurable disease demands an excess of caution, even if the transmission rate is dramatically lower than other diseases. You don't need each patient to infect a hundred other people for it to spread; so long as it is more than one, it is a growing problem.
The risk here isn't because the disease is especially contagious; it is because the containment and treatment is especially costly. Doctor diagnoses someone with the flu, they send them home and tell them to drink plenty of wayer and get plenty of rest. In an extreme case, they may push IV fluids and keep a few days for observation.
With Ebola that becomes weeks of quarantine and treatment, stringent sterilization procedures, and monitoring anyone they've come in contact with. It wouldn't take an especially large outbreak to strain and ultimately exhaust available resources. And as necessity forces compromises in care and treatment by untrained individuals, transmission rates will spike.
Really not a viable treatment course. Even with monitoring and proactive care, your chances of survival are about even. In isolation, pretty much a death sentence.
Coughing and sneezing may be symptoms of specific diseases, but they are also reflexes that are not necessarily linked to a specific disease. People may cough because they aspirated saliva, or because they just came in from smoking. People may sneeze because its ragweed season, of because of the judiciously applied perfume of the person next to them (or the guy who just came in from smoking), or even as a reaction to a brightly lit waiting room.
Possibly a bigger risk than the waiting room itself would be the bathrooms. The likelihood of contamination when there is evacuation of infectious material, as well as repeated bare skin contact with the same surface by a stream of individuals strikes me as very high, especially if some patients wait long enough that they have developed rashes.
In iso+lation, this is a solvable problem, but if a critical mass of patients develops, it can quickly get out of hand. Especially now, as we are enter flu season.
Separation is not enough when the virus can survive outside the body for extended periods. All it takes is for one infected individual to rest their sweaty hands on an armrest and that seat becomes a possible vector. There is a reason people are wearing those suits, and it is not because they look cool.
Sending people with sick kids is not a particularly viable long term solution. Even if it reduces the immediate risk to the general population, it puts the rest of their family at grave risk and is a likely death sentence for the child. Homes are simply not equipped to deliver the necessary palliative care needed by patients, nor are most people trained in the necessary sanitation procedures to prevent transmission.
People with fevers sweat, they cough, they sneeze. Droplet transmission is a serious threat, especially in cramped conditions. No licking necessary. But then you throw children in the mix, and there will be licking and mouthing of potentially contaminated items. And sick kids that want to be held by mommy or daddy, and will sneeze directly in their face.
Not saying that we have reason to panic now, but it is fatuous to dismiss the very real challenges of effective containment once the disease becomes endemic to a particular population.
Java is going nowhere. In addition to being in most phones (Android, Jave ME), it is in every Blu-Ray player (BD-J), every cable box (OCAP), cash registers, ATMs and voting machines. And that isn't even touching on enterprise, web and desktop applications.
Take a look at most language rankings and Java remains near or at the top, whether you look at Tiobe, PyPL, RedMonk, IEEE Spectrum, or the various job surveys published by the likes of Dice.com and eWeek.
JRuby and Rubinius have been using JIT for years.
And LuneOS, and Tizen.
Java has a vast ecosystem, excellent threading and concurrency support, robust monitoring and debugging tools, and can rival (or exceed) the performance of traditional compiled languages.
This is true for both small scale and large scale problems. For example, I wrote a little tool to do LDIF transforms in perl. Six hours later, it wasn't even half finished. Rewrote it using a Java library (UnboundSDK) and it finished in about twenty-five minutes.
On the other end of spectrum, I wrote a load-testing application that scaled cleanly to tens of thousands of threads. In a couple of hours. With no experience writing anything to that scale before.
(And the idea that Java is strictly Android these days is absurd. Your cable box runs Java. So does your blu-ray player. Along with ATMs, cash registers, voting machines, any number of enterprise applications, webservices, etc, etc. It is an incredibly pervasive language.)
It also turns out you can implement everything in plain Java libraries. In fact it is a heck of a lot easier, since you don't need to wrap the C modules; everything Just Works.
How big a stack do you need to match a 1320 tape library? Even using 4TB disks you're talking 825 disks, which means 51 enclosures. And then four racks to hold those enclosures. And enough floor space to hold those racks. And enough circuits to power those racks.
At that level of scale, tape is simply a better option for archival storage.
Eh? Both T-Mobile and AT&T (and Verizon, actually) offer no-contract service. Not one or two year. No year. Now you might finance a phone through them, and be on the hook for paying that, but that is not the same thing as being under a service contract.