Oh please. Your argument is total crap. Hunting is deeply ingrained behavior in humans? And you need to express that urge? Then why use a gun? Or are you too "squeamish" to tackle an animal with your bare hands?
Just because taking a shit is "deeply ingrained behavior" doesn't mean I should worship my feces. Neither does it mean that shit makes me "squeamish". It's just that us "civilized people" prefer a sane approach to the problem of shit disposal instead.
Look, the fact that stupid Americans cling to their guns, while they spend millions on a drug war that benefits nobody, just means that Americans are stupid. Enjoy your stupid guns, your stupid death penalty, and your stupid RIAA/MPAA. We'll enjoy our weed and swap some more music.
Bah, why does talk about cryptography always turn into a "for the people, by the people" kind of thing? The general public has just as much use for munitions-grade encryption as it has for bulletproof cars. Let's just say that the moment everybody starts driving around in bulletproof cars I'm getting out of here. What a crock.
Maybe you should read the interview again
on
Deep Algorithms?
·
· Score: 1
In the interview, Knuth also repeatedly remarks on the importance of the "individual bricks" over "milestones" and top-ten lists. So maybe you should read the interview again.
Yeah, that can work. It is an approach with rather severe limitations, but as it turns out, many real world applications fit nicely within those constraints. Most people on Slashdot would shove this under the heading "security through obscurity" and tell you that it doesn't work, but that's not really true. It's more of the difference in viewpoint between the needs of the actual users of crypto, i.e. the people who have something to hide, and the people implementing or designing crypto, i.e. the locksmiths. Needless to say the locksmiths always peddle the biggest safe.
No, I'm pointing to a design flaw in Sun's implementation and saying that it is a design flaw in Sun's implementation. But, if you want me to turn this into a Java flame, yes, it is a implementation flaw that was inspired by a fundamental design flaw in the Java language, namely the lack of a "delete" operator. That aside, considering that Sun is the one proposing "Java for games", I think it makes sense to examine their track record delivering an efficient Java platform is not very good.
This is inane! When you select something that may have side effects, and yes, one of those sideeffects can be "activation". What is the problem? Sheesh.
Jezus christ. Double click is open. Single click is select. This works for links too. There is no inconsistency. If you select an icon, then a side effect is that the icon becomes darker. If you select a tree, then it expands. If you select a link, then it opens. Yes, so the meanings can overlap. So what?
Not if you recompile Java bytecode in one thread and load your game media in another. It's called overlapping CPU-bound and IO-bound processes.
You can't just arbitrarily pick a point in the life of a program and say "this is where I start counting", and then at some arbitrary later point say, "see, it got faster". Before you even get to the point where you can load your game media, you will have to initialize the virtual machine, verify the bytecode, and initialize all the libraries. Then the memory you squander has to be collected later, and you don't count that cost either. So I'm not sure what you are trying to accomplish by sounding authoritive on a subject you are not even trying to address.
Memory is cheap.
That does not mean it does not need to be managed, and it does not help that Java's memory management model is naive, primitive and limiting.
1. To my best knowledge, Sun's JVM never returns free memory to the OS[1]. If you have an interactive application, and you suddenly need a lot of memory (e.g. the user opens a large file), then this memory will be lost for the program's lifetime. While there are ways to ensure that the heap never grows beyond a certain point, this comes at the cost of making your program crash if it needs more memory (even though the operating system has plenty of memory available to it). I figured that with the long overdue death of Classic MacOS we had seen the last of this kind of stick-figure memory management. I was wrong.
2. Memory is cheap, but garbage collection can make it expensive. Garbage collecting C allocators such as Boehm's can waste something like 70% of the allocated memory and Java is not much better. Moreover, because Java renders the process of garbage collection completely opaque, there is very little (read that as very little implicit and zero explicit) information that the programmer can feed to the allocator to make it more efficient. Did they even meaningfully spec System.gc() yet?
[1] I've never seen it return memory on Linux and Sun. On Windows it is a little bit better, and you actually get a few commandline switches (nothing you can change at runtime for obvious but stupid reasons) that affect the allocator's behaviour in ill-defined ways.
When Charles Lindbergh had to build a plane to cross the Atlantic, he decided to build a plane with just a single, big fat engine. He won. His competitors, using expensive four-engine designs, either died trying or barely escaped with their lives.
Intuitively, extra engines add extra safety to a plane. In practice, it does not work that way. Similarly, Java affords a programmer extra safety, as well as some convenience. But again, in practice, it does not work that way.
What Lindbergh realized was, that when you add an engine to a plane, it means you need more fuel. But that means you need more room for fuel. Which means your plane gets bigger and heavier, which means you need another engine, if you want to maintain your safety margin. But that means more fuel, and this goes on forever until you shout "stop!" and begin the delicate balancing act of finding a sweet spots somewhere in this mess. Which is difficult -- although it's not anywhere near as difficult as it was in Lindbergh's time.
In programming, it is still very difficult. And Java is nowhere near the sweet spot. In fact, for this particular application, i.e. gaming, it is so far removed from the sweet spot, that you have to start asking yourselves, "why bother with all these engines and the balancing act? why not just build a single reliable engine instead?".
For example, Java advocates like to point to the fact that buffer overflows in Java cannot happen. What they really mean is that Java will not allow you to reference out of bounds array elements. Of course what they really mean by that is that it is very difficult to exploit these kinds of errors to execute malicious code (which sort of boils down to the rather empty truth that Java is not C, but that aside). But guys. Hello? Referencing non-existing array elements is a critical error. Whether it happens in Java or C, your program will crash and burn and take all non-persistent state with it. The only benefit Java offers here is that at least it protects the underlying system, but what kind of benefit is that, if the Java software is supposed to control, well, let's say, a plane engine?
In other words, what the argument fails to recognize is that the true value is created in the top layer, and when that layer (i.e. your application) fails, that is when the real damage occurs. Protecting the lower layers is fine and necessary and dandy, but in most cases, the lower layers are not where the value is. And when it comes to the point that you program defensively against your own code, i.e. stop trusting yourself and rely on the machine to resolve the conflicts, that is when you have begun adding engines and fuselage and engines and more fuselage. There's very few people who can get it right and they take an awful lot of time to do it.
The more advanced the "on-the-fly" technology, the more unpredictable delays you introduce, the longer your startup times become, and the more memory you use. It's wrong to think that better hardware will absorb those costs because it's not true.
Actually the Java developers are still trying to get people to upgrade to the new version of the JDK which supports stuff like, oh, I don't know, setting the creation date on a file.
I get thoroughly disgusted by all these reasonable types harping on about the "rights of the artists". Why do these people feel the need to write comments on/. about the need to balance the moral equation? Who cares about the rights of these so-called artists? I know I don't. And what difference does it make? Zilch. Do I copy less stuff because it rips off the artist? No. Do I copy more stuff because it rips off the artist? No. So what the fuck is with these people?
If this is the kind of retarded farmboi common sense (spit! ka-chunk) wisdom that passes for insight nowadays then I'm not surprised present day tech is so prone to breakage.
Pioneer 10 cost $75 million to build which translates into approx. $350 million current day prices. The TRDS project has $825 allotted for 3 sattelites that are far, far more capable than Pioneer 10, and have to fulfill a far, far more complicated role.
Pioneer 10 might have been good, but it was also expensive, and took over three years to build. Good, fast, cheap. Pick two.
What kind of believer calls himself "Pussy Is Money"? You might not be dumb so I am not going to assume that you are. But your argument is like a cardboard template. Bell rings, georgeb drools.
The health industry spends billions and billions of dollars on high-tech gear that ostensibly will one day offer the cure for cancer (carrot A) or prolong life indefinitely (carrot B). Meanwhile, tens of thousands of Americans die each year as a result of traffic accidents, fatty foodstuffs, and gun related violence. But teaching people how to take care of themselves is not half as sexy as high-tech tomfoolery, and actually caring for people who are sick as opposed to plugging them into some kind of machine, or sedating them with drugs, well, that is just a drag.
I am not opposed to research. And to be frank, pacemakers are not a bad idea. But this has become an industry that perceives its patients as either expenses or experiments, something to dispose of as soon as possible, so that work can proceed on securing funds for the really exciting gee-whiz stuff. Just like bad sysadmins hate their users, bad doctors hate their patients. And there is a lot of room for bad doctors nowadays.
What you should do is look at healthcare expenses over the past two or three decades and compare them with the number of dead in those years. It's not a secret so I won't insult your intelligence: just go look it up.
As for death. Death is not something to be conquered. It is not something to be welcomed either. But I recommend you just accept it. Man grows strong, man grows old, man grows maggots. Perhaps not the best setup imaginable. But it will have to do.
It figures that you would be a gambling man, if you enjoy getting sucked into the spiral of checkups, experiments, more checkups, and the gutless doctors trying to get a publication out of the unexpected sweltering sores on your chest. Enjoy the clusterfuck, you might even get lucky.
Slashdot Mirror
Just because taking a shit is "deeply ingrained behavior" doesn't mean I should worship my feces. Neither does it mean that shit makes me "squeamish". It's just that us "civilized people" prefer a sane approach to the problem of shit disposal instead.
For people like you, I'd suggest diapers.
Your $20 is better spent on hookers and booze. Celebrate the end of the world in style.
Look, the fact that stupid Americans cling to their guns, while they spend millions on a drug war that benefits nobody, just means that Americans are stupid. Enjoy your stupid guns, your stupid death penalty, and your stupid RIAA/MPAA. We'll enjoy our weed and swap some more music.
In other words, you are an authoritarian theocrat.
Bah, why does talk about cryptography always turn into a "for the people, by the people" kind of thing? The general public has just as much use for munitions-grade encryption as it has for bulletproof cars. Let's just say that the moment everybody starts driving around in bulletproof cars I'm getting out of here. What a crock.
In the interview, Knuth also repeatedly remarks on the importance of the "individual bricks" over "milestones" and top-ten lists. So maybe you should read the interview again.
Britney can voluntarily enter the contract. Gateway reasonably cannot.
Yeah, that can work. It is an approach with rather severe limitations, but as it turns out, many real world applications fit nicely within those constraints. Most people on Slashdot would shove this under the heading "security through obscurity" and tell you that it doesn't work, but that's not really true. It's more of the difference in viewpoint between the needs of the actual users of crypto, i.e. the people who have something to hide, and the people implementing or designing crypto, i.e. the locksmiths. Needless to say the locksmiths always peddle the biggest safe.
You could say it's more consistent to first click to focus, then press a key to activate, I suppose. But frankly I'm bored with the entire discussion.
No, I'm pointing to a design flaw in Sun's implementation and saying that it is a design flaw in Sun's implementation. But, if you want me to turn this into a Java flame, yes, it is a implementation flaw that was inspired by a fundamental design flaw in the Java language, namely the lack of a "delete" operator. That aside, considering that Sun is the one proposing "Java for games", I think it makes sense to examine their track record delivering an efficient Java platform is not very good.
This is inane! When you select something that may have side effects, and yes, one of those sideeffects can be "activation". What is the problem? Sheesh.
Jezus christ. Double click is open. Single click is select. This works for links too. There is no inconsistency. If you select an icon, then a side effect is that the icon becomes darker. If you select a tree, then it expands. If you select a link, then it opens. Yes, so the meanings can overlap. So what?
1. To my best knowledge, Sun's JVM never returns free memory to the OS[1]. If you have an interactive application, and you suddenly need a lot of memory (e.g. the user opens a large file), then this memory will be lost for the program's lifetime. While there are ways to ensure that the heap never grows beyond a certain point, this comes at the cost of making your program crash if it needs more memory (even though the operating system has plenty of memory available to it). I figured that with the long overdue death of Classic MacOS we had seen the last of this kind of stick-figure memory management. I was wrong.
2. Memory is cheap, but garbage collection can make it expensive. Garbage collecting C allocators such as Boehm's can waste something like 70% of the allocated memory and Java is not much better. Moreover, because Java renders the process of garbage collection completely opaque, there is very little (read that as very little implicit and zero explicit) information that the programmer can feed to the allocator to make it more efficient. Did they even meaningfully spec System.gc() yet?
[1] I've never seen it return memory on Linux and Sun. On Windows it is a little bit better, and you actually get a few commandline switches (nothing you can change at runtime for obvious but stupid reasons) that affect the allocator's behaviour in ill-defined ways.
Intuitively, extra engines add extra safety to a plane. In practice, it does not work that way. Similarly, Java affords a programmer extra safety, as well as some convenience. But again, in practice, it does not work that way.
What Lindbergh realized was, that when you add an engine to a plane, it means you need more fuel. But that means you need more room for fuel. Which means your plane gets bigger and heavier, which means you need another engine, if you want to maintain your safety margin. But that means more fuel, and this goes on forever until you shout "stop!" and begin the delicate balancing act of finding a sweet spots somewhere in this mess. Which is difficult -- although it's not anywhere near as difficult as it was in Lindbergh's time.
In programming, it is still very difficult. And Java is nowhere near the sweet spot. In fact, for this particular application, i.e. gaming, it is so far removed from the sweet spot, that you have to start asking yourselves, "why bother with all these engines and the balancing act? why not just build a single reliable engine instead?".
For example, Java advocates like to point to the fact that buffer overflows in Java cannot happen. What they really mean is that Java will not allow you to reference out of bounds array elements. Of course what they really mean by that is that it is very difficult to exploit these kinds of errors to execute malicious code (which sort of boils down to the rather empty truth that Java is not C, but that aside). But guys. Hello? Referencing non-existing array elements is a critical error. Whether it happens in Java or C, your program will crash and burn and take all non-persistent state with it. The only benefit Java offers here is that at least it protects the underlying system, but what kind of benefit is that, if the Java software is supposed to control, well, let's say, a plane engine?
In other words, what the argument fails to recognize is that the true value is created in the top layer, and when that layer (i.e. your application) fails, that is when the real damage occurs. Protecting the lower layers is fine and necessary and dandy, but in most cases, the lower layers are not where the value is. And when it comes to the point that you program defensively against your own code, i.e. stop trusting yourself and rely on the machine to resolve the conflicts, that is when you have begun adding engines and fuselage and engines and more fuselage. There's very few people who can get it right and they take an awful lot of time to do it.
The more advanced the "on-the-fly" technology, the more unpredictable delays you introduce, the longer your startup times become, and the more memory you use. It's wrong to think that better hardware will absorb those costs because it's not true.
That sucks man, it really does. Don't worry. We'll steal OpenOffice for you.
Actually the Java developers are still trying to get people to upgrade to the new version of the JDK which supports stuff like, oh, I don't know, setting the creation date on a file.
I get thoroughly disgusted by all these reasonable types harping on about the "rights of the artists". Why do these people feel the need to write comments on /. about the need to balance the moral equation? Who cares about the rights of these so-called artists? I know I don't. And what difference does it make? Zilch. Do I copy less stuff because it rips off the artist? No. Do I copy more stuff because it rips off the artist? No. So what the fuck is with these people?
Only this is about the user box space, not about journals.
You didn't look up the numbers, did you. Oh well. Good health and many years for you and your granddad.
Pioneer 10 cost $75 million to build which translates into approx. $350 million current day prices. The TRDS project has $825 allotted for 3 sattelites that are far, far more capable than Pioneer 10, and have to fulfill a far, far more complicated role.
Pioneer 10 might have been good, but it was also expensive, and took over three years to build. Good, fast, cheap. Pick two.
The health industry spends billions and billions of dollars on high-tech gear that ostensibly will one day offer the cure for cancer (carrot A) or prolong life indefinitely (carrot B). Meanwhile, tens of thousands of Americans die each year as a result of traffic accidents, fatty foodstuffs, and gun related violence. But teaching people how to take care of themselves is not half as sexy as high-tech tomfoolery, and actually caring for people who are sick as opposed to plugging them into some kind of machine, or sedating them with drugs, well, that is just a drag.
I am not opposed to research. And to be frank, pacemakers are not a bad idea. But this has become an industry that perceives its patients as either expenses or experiments, something to dispose of as soon as possible, so that work can proceed on securing funds for the really exciting gee-whiz stuff. Just like bad sysadmins hate their users, bad doctors hate their patients. And there is a lot of room for bad doctors nowadays.
What you should do is look at healthcare expenses over the past two or three decades and compare them with the number of dead in those years. It's not a secret so I won't insult your intelligence: just go look it up.
As for death. Death is not something to be conquered. It is not something to be welcomed either. But I recommend you just accept it. Man grows strong, man grows old, man grows maggots. Perhaps not the best setup imaginable. But it will have to do.
It figures that you would be a gambling man, if you enjoy getting sucked into the spiral of checkups, experiments, more checkups, and the gutless doctors trying to get a publication out of the unexpected sweltering sores on your chest. Enjoy the clusterfuck, you might even get lucky.