Its unclear if you're complaining that you can't launch remote X apps on a Wayland Ubuntu desktop or if you can't launch X apps from a Wayland Ubuntu desktop on a remote machine. However, neither is the case. You can run an X server on top of Wayland (that covers #1) and you can still launch X apps on the Wayland machine as long as the libraries are there (that covers #2 and I do that all the time to run an XTerm on my windows box).
Get a PS3 and either a network attached storage device capable of running twonkymedia, or a small quiet PC you can stick in the closet running linux and PS3 Media Server.
Some would say because its a fine line from there to 'buying child porn isn't illegal because the act itself can't be undone'.
Others would say because having federal funds used to do a thing becomes in and of itself a political statement. i.e. its one thing to destroy cells, but another thing to be paid by the government to do it.
Personally I think the whole issue is retarded. I don't care that they're human embryos, they're never going to be people.
I got that too. While I'm largely in the Kurzweil camp in this whole thing, he's misreading Meyer point about the environment. A strand of DNA dropped on the moon isn't ever going to form a brain any more than dropping a paper containing source code on a computer will cause it to run the program. It needs a very specific environment and its easy to see that there are lots of small environmental imperfections that can fuck up brain development in a child. But even though Kurzweil doesn't address that, I really think Meyers is overstating the ultimate difficulty of simulating the environment or achieving an understanding of the brain through other means, like direct examination of the information processing structure of the finished product.
you don't need to simulate electrons in a semi-conductive material at specific temperatures in order to build a complete working emulator for an old computer.
That analogy is predicated on the idea that we can simulate the logic functions of the brain without simulating its physics, but we're a long way from understanding the logical functions of the brain. I think the view Kurzweil takes, and that Meyers misses, is that the Genome is the kernel of information needed to create a brain (granted, within a given environment, in much the same was as the linux kernel is only a bunch of ones and zeros till its placed in the appropriate location on a functioning computer). I would posit that Kurzewil believes that in the next 50 years, processing power and storage will advance to the point where we can actually simulate the unfolding of the human genome at a cellular level, up to the creation of a complete body. Once we have that 'digital person', it will be much easier to start the work of doing the reverse engineering of the brain's logical structure.
You should ask this on Stack Overflow, or better yet, see if there's an existing question that maps closely to this one and engage in the discussion there. Its less full of howler monkeys and asshats than Slashdot, and generally gets more useful and serious answers if your question is programming related.
The big difference here is that back when the polar caps melted last time, there were no cities. Cities can't just up and move. If the water levels rise significantly, millions of people will die. Billions will be displaced.
Heisenberg was talking about subatomic particles, not specks of dust. Its basically a consequence of not being able to measure both the speed or position of a subatomic particle without affecting the other property. The more accurately you measure one, the less you know about the other. While this principle does apply to macroscopic objects like dust particles, the level of uncertainty about the size and position of something macroscopic (even something as small as a dust particle) is vanishingly small (like on the order of the width of an atom).
Lots of professional developers who work for other companies also contribute to open source. Some of them might be in the habit of reusing the same password in various locations, or use passwords that give a clue as to how they might generate them in a less than secure fashion. Its not a smart thing to reuse passwords but it happens. Now the attackers might have leads on how to get into more valuable targets.
The point of the code that I wrote was that it makes N! function calls in each language, thus comparing apples to apples. The code you wrote calculates N! using 0 function calls. Of course your code runs faster, it makes no functions calls instead of half a billion and acts as if the point is to calculate 12!.
Yes, the pre-processor can convert an arbitrary example whose point is to execute half a billion function calls into no function calls. By one measure you've sped up the program, but by another you've broken it because its no longer a comparison of the same property in two languages (speed of making a function call). You've also made it harder to debug, breaking one of the cardinal rules of software development, that maintainability is more important than performance gain. If you were writing a full size program and had inserted this into your code, you'd have also broken one of the cardinal rules of optimization: "Don't, not until you've actually benchmarked the program and found out where the bottlenecks are".
The preprocessor is virtually never used the way you demonstrate. Its primary use in every environment I've seen (and I've seen a few) is to include a shit-ton of macros in one universally included header to smooth over differences between platforms and compilers. Occasionally its used for evil, like shoehorning in class metadata or trying to overcome the insufficiently defined RTTI infrastructure in C++.
You can argue the benefits of the macro pre-processor till you're blue in the face, but when it comes down to it, 9 out of 10 use cases for the preprocessor are for solving problems that simply don't exist in Java, and the performance use case you're making is dubious at best.
A difference of 40% in favour of c is hardly trivial
You claimed that function call overhead was somehow responsible for some perceived slowness in Java. This implies some sort of massive difference in function call overhead, but the test demonstrates less than a single order of magnitude.
bytecode is NOT compiled code
It is actually, by virtue of a) not being source code and b) being the output of the java compiler. From Wikipedia: Bytecode is a term which has been used to denote various forms of instruction sets designed for efficient execution by a software interpreter as well as being suitable for further compilation into machine code.
[bytecode] can NEVER be executed directly, so it HAS to be interpreted at runtime
I never suggested that bytecode was executed by the host processor. If you want call execution by the JVM 'interpreted' as opposed to 'executing compiled code' you can try to make that distinction, but its certainly not interpreting the original sourcecode, and as I believe I pointed out, the Sun JVM is perfectly capable of turning the bytecode into actual machine code for the current platform. You're dangerously close to veering into 'no true Scotsman' territory here with your arguments. Go read the linked discussion and articles. Or you could... you know... make a few flat out assertions that are at best misleading or at worst completely wrong.
You sir, are speaking out of your ass. Here are some hard numbers for you. I wrote the same test in C and in Java, which is basically a test of function call speed. Here is the Java version:
public class recurse {
public static void main(String[] args) { factorialRecurse(12); }
public static void factorialRecurse(int val) { for (int i = 0; i < val; ++i) { factorialRecurse(val - 1); } } }
and the C version
void factorialRecurse(int val) { int i =0; for (i ; i < val; ++i) { factorialRecurse(val - 1); } }
The code in question was compiled and executed. The java version took about 7 seconds to run. The C version varied between 10 seconds for the O2 level optimizations and 5 seconds for the O3 level optimizations and above. Hardly compelling evidence for 'Java function calls are slow'.
Java is interpreted, So before everyone flames - yet again - that it's "compiled" - do your research and get over it already.
Once again you are engaged in rectal whistling. Java is compiled to non-platform specific bytecode, and then depending on the JVM may or may not be transformed into CPU specific instructions at runtime. There are also tools out there to compile Java code directly to machine code as well as interpreters for C and C++. There's a good discussion of the intepreted vs compiled topic here
Personally, I disagree. If you artificially increase the life span of the overpopulation, the problem becomes even more critical, and fast.
I initially agreed, but on consideration I think the GP poster has a point (or rather Melinda Gates and Charlie Rose have a point). Resources spent on raising a child and having them die before reaching an age where they can contribute to society are basically completely wasted resources. If you look at both sides of the equation, you have to decide, will spending this $10 billion on some sort of birth control measure (which realistically is just going to be some sort of education program) conserve more resources than the ones being wasted on children who die. It doesn't take much to convince me that it won't and that improving vaccination coverage, which directly saves lives, will have a positive impact.
It looks like they jumped through an enormous number of hoops to ensure that you couldn't add memory to this device with things like micro-SD, specifically so they could do price hiking like this.
Most of those issues can be figured out on earth actually. And implementing them is always going to be much less dangerous and error prone on Mars than in a pure vacuum. The moon makes a good observatory location, but lacks the natural resources that mars has for supporting a colony.
Step 1, create a (mostly?) self-sufficient colony on the moon. We'll need this for Mars, anyway...
Uh... no. Landing on the moon is harder than landing on mars. A moon colony would actually be a waste of resources (in terms of getting a colony on Mars)
Soft-landing cargo on the moon (to then send to mars) is harder than just sending it to Mars directly, and most of the mats we'd need to land on Mars originate on Earth, not the Moon.
Slashdot Mirror
Its unclear if you're complaining that you can't launch remote X apps on a Wayland Ubuntu desktop or if you can't launch X apps from a Wayland Ubuntu desktop on a remote machine. However, neither is the case. You can run an X server on top of Wayland (that covers #1) and you can still launch X apps on the Wayland machine as long as the libraries are there (that covers #2 and I do that all the time to run an XTerm on my windows box).
Get a PS3 and either a network attached storage device capable of running twonkymedia, or a small quiet PC you can stick in the closet running linux and PS3 Media Server.
While cell phones are nifty and I wouldn't want to live day to day without mine, I think this is largely missing the point of Burning Man.
Others would say because having federal funds used to do a thing becomes in and of itself a political statement. i.e. its one thing to destroy cells, but another thing to be paid by the government to do it.
Personally I think the whole issue is retarded. I don't care that they're human embryos, they're never going to be people.
I got that too. While I'm largely in the Kurzweil camp in this whole thing, he's misreading Meyer point about the environment. A strand of DNA dropped on the moon isn't ever going to form a brain any more than dropping a paper containing source code on a computer will cause it to run the program. It needs a very specific environment and its easy to see that there are lots of small environmental imperfections that can fuck up brain development in a child. But even though Kurzweil doesn't address that, I really think Meyers is overstating the ultimate difficulty of simulating the environment or achieving an understanding of the brain through other means, like direct examination of the information processing structure of the finished product.
you don't need to simulate electrons in a semi-conductive material at specific temperatures in order to build a complete working emulator for an old computer.
That analogy is predicated on the idea that we can simulate the logic functions of the brain without simulating its physics, but we're a long way from understanding the logical functions of the brain. I think the view Kurzweil takes, and that Meyers misses, is that the Genome is the kernel of information needed to create a brain (granted, within a given environment, in much the same was as the linux kernel is only a bunch of ones and zeros till its placed in the appropriate location on a functioning computer). I would posit that Kurzewil believes that in the next 50 years, processing power and storage will advance to the point where we can actually simulate the unfolding of the human genome at a cellular level, up to the creation of a complete body. Once we have that 'digital person', it will be much easier to start the work of doing the reverse engineering of the brain's logical structure.
You should ask this on Stack Overflow, or better yet, see if there's an existing question that maps closely to this one and engage in the discussion there. Its less full of howler monkeys and asshats than Slashdot, and generally gets more useful and serious answers if your question is programming related.
That's not a 'bug'. Its an incredibly bad design decision.
The big difference here is that back when the polar caps melted last time, there were no cities. Cities can't just up and move. If the water levels rise significantly, millions of people will die. Billions will be displaced.
Solr in front of Lucene is a perfectly reasonable way to index highly structured information and allows structured queries.
Whoops, that was supposed to be in reply to http://science.slashdot.org/comments.pl?sid=1663226&cid=32328154
Heisenberg was talking about subatomic particles, not specks of dust. Its basically a consequence of not being able to measure both the speed or position of a subatomic particle without affecting the other property. The more accurately you measure one, the less you know about the other. While this principle does apply to macroscopic objects like dust particles, the level of uncertainty about the size and position of something macroscopic (even something as small as a dust particle) is vanishingly small (like on the order of the width of an atom).
I seldom spend all my mod points I used some there.
Didn't you negate any moderation you did by posting in the same discussion?
It's not like it's Citibank.
Lots of professional developers who work for other companies also contribute to open source. Some of them might be in the habit of reusing the same password in various locations, or use passwords that give a clue as to how they might generate them in a less than secure fashion. Its not a smart thing to reuse passwords but it happens. Now the attackers might have leads on how to get into more valuable targets.
The point of the code that I wrote was that it makes N! function calls in each language, thus comparing apples to apples. The code you wrote calculates N! using 0 function calls. Of course your code runs faster, it makes no functions calls instead of half a billion and acts as if the point is to calculate 12!.
Yes, the pre-processor can convert an arbitrary example whose point is to execute half a billion function calls into no function calls. By one measure you've sped up the program, but by another you've broken it because its no longer a comparison of the same property in two languages (speed of making a function call). You've also made it harder to debug, breaking one of the cardinal rules of software development, that maintainability is more important than performance gain. If you were writing a full size program and had inserted this into your code, you'd have also broken one of the cardinal rules of optimization: "Don't, not until you've actually benchmarked the program and found out where the bottlenecks are".
The preprocessor is virtually never used the way you demonstrate. Its primary use in every environment I've seen (and I've seen a few) is to include a shit-ton of macros in one universally included header to smooth over differences between platforms and compilers. Occasionally its used for evil, like shoehorning in class metadata or trying to overcome the insufficiently defined RTTI infrastructure in C++.
You can argue the benefits of the macro pre-processor till you're blue in the face, but when it comes down to it, 9 out of 10 use cases for the preprocessor are for solving problems that simply don't exist in Java, and the performance use case you're making is dubious at best.
A difference of 40% in favour of c is hardly trivial
You claimed that function call overhead was somehow responsible for some perceived slowness in Java. This implies some sort of massive difference in function call overhead, but the test demonstrates less than a single order of magnitude.
bytecode is NOT compiled code
It is actually, by virtue of a) not being source code and b) being the output of the java compiler. From Wikipedia: Bytecode is a term which has been used to denote various forms of instruction sets designed for efficient execution by a software interpreter as well as being suitable for further compilation into machine code.
[bytecode] can NEVER be executed directly, so it HAS to be interpreted at runtime
I never suggested that bytecode was executed by the host processor. If you want call execution by the JVM 'interpreted' as opposed to 'executing compiled code' you can try to make that distinction, but its certainly not interpreting the original sourcecode, and as I believe I pointed out, the Sun JVM is perfectly capable of turning the bytecode into actual machine code for the current platform. You're dangerously close to veering into 'no true Scotsman' territory here with your arguments. Go read the linked discussion and articles. Or you could... you know... make a few flat out assertions that are at best misleading or at worst completely wrong.
and the C version
The code in question was compiled and executed. The java version took about 7 seconds to run. The C version varied between 10 seconds for the O2 level optimizations and 5 seconds for the O3 level optimizations and above. Hardly compelling evidence for 'Java function calls are slow'.
Java is interpreted, So before everyone flames - yet again - that it's "compiled" - do your research and get over it already.
Once again you are engaged in rectal whistling. Java is compiled to non-platform specific bytecode, and then depending on the JVM may or may not be transformed into CPU specific instructions at runtime. There are also tools out there to compile Java code directly to machine code as well as interpreters for C and C++. There's a good discussion of the intepreted vs compiled topic here
This way you don't incur the overhead of a function call to pass the arguments from your custom string_copy to strcpy.
Right... cause function call overhead is usually the limiting factor in a program's performance.
Their their, it'll be all right. Don't get you're blood pressure up.
I initially agreed, but on consideration I think the GP poster has a point (or rather Melinda Gates and Charlie Rose have a point). Resources spent on raising a child and having them die before reaching an age where they can contribute to society are basically completely wasted resources. If you look at both sides of the equation, you have to decide, will spending this $10 billion on some sort of birth control measure (which realistically is just going to be some sort of education program) conserve more resources than the ones being wasted on children who die. It doesn't take much to convince me that it won't and that improving vaccination coverage, which directly saves lives, will have a positive impact.
I think you underestimate the compulsion to accept hardship as a consequence of reproduction.
It looks like they jumped through an enormous number of hoops to ensure that you couldn't add memory to this device with things like micro-SD, specifically so they could do price hiking like this.
Most of those issues can be figured out on earth actually. And implementing them is always going to be much less dangerous and error prone on Mars than in a pure vacuum. The moon makes a good observatory location, but lacks the natural resources that mars has for supporting a colony.
Uh... no. Landing on the moon is harder than landing on mars. A moon colony would actually be a waste of resources (in terms of getting a colony on Mars)
Soft-landing cargo on the moon (to then send to mars) is harder than just sending it to Mars directly, and most of the mats we'd need to land on Mars originate on Earth, not the Moon.