Plus, what we don't find a direct commmercial use for we can always drop down the gravity well on terrorists at really nice velocities. Kinetic energy is our friend.
No, that's exactly wrong. Kinetic energy is precisely what prevents the asteroids from falling into the sun. To take an asteroid and "drop it down the energy well" would require a huge amount of braking to deform the asteroid's nearly-circular orbit into an elliptical transfer orbit that collides with Earth.
What exactly did you think was keeping the asteroids up there?
I'd like to see your evidence that it eats processor cycles.
The only such claim I ever saw said that Reiser had a higher CPU utilization, in percentage terms. But that's just what happens when you spend less time on I/O.
Imagine this benchmark scenario: Filesystem A takes 10 seconds and has 20% CPU usage. Filesystem B takes 2 seconds and has 90% cpu usage. Some would claim that Filesystem B is eating CPU cycles, but in fact it is consuming less processor time! (1.8 versus 2.0 CPU seconds.)
IIRC, the situation with ReiserFS is similar. It uses marginally more CPU time (maybe 10% or so) but the CPU utilization as a percentage seems much higher because it spends so much less time doing I/O.
Regarding your "acronym abuse" thing, it's a joke. It started with everyone saying "I am not a lawyer" before giving legal advice, which became "IANAL". Then, others started using it as a joke for any expert profession, like "IANARS (I Am Not A Rocket Scientist)".
Am I wrong, or was this password meant to prevent tampering with the file contents? My point is it isn't anywhere close to achieving this.
Even if they used some complex password scheme, it would still not be difficult to brute force it...
I'm not sure what you mean by "difficult", but a run-of-the-mill digital signature would require something like a distributed computing effort to brute-force. I consider that pretty difficult.
Well, that's one way to look at it I guess. But if the security were only as "weak" as digital signature technology allows, that would be pretty damn strong. It would be much more like a padlock than an FBI warning.
Quite wrong. Many languages have neither pointers nor object references (Fortran, Prolog, Haskell, etc.).
Uh, I'll give you Fortran, but I'd be surprised to see a Prolog or Haskell implementation that isn't rife with pointers. Haskell, in particular, has a call-by-need semantics that means every piece of data could potentially be a pointer to a closure.
For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4.
The stack is dominated by data, not by those two pointers, so that is insignificant (if it were signficant, it woul be easy to avoid, too).
What in the world are you talking about? I'm talking about the stack on an AMD64, where push and pop instructions always deal with 8-byte quantities.
Anyway, what "two pointers" are you referring to? The return address and frame pointer?
Your page tables only hold half as many entries.
That depends on how they are represented.
Sorry, I thought we were talking about AMD64.
In languages like C, C#, or Fortran, in high-performance, memory-critical code, the heap will be dominated by large chunks of non-pointer data (usually, multidimensional arrays or arrays of value classes).
To paraphrase: in some code, memory will not be dominated by pointers. I'll grant you that.
I think you're talking about scientific (loops-and-arrays) code that has been carefully optimized. I'll grant you that a 64-bit processor shouldn't be detrimental to that code. But there's a whack of OO-style code out there that is not dominated by arrays, and that code pays for 64 bits even if it doesn't need them.
But you don't move more bits per instruction if you don't have to. The Opteron chips run 32bit code faster than previous Athlons. 64bit processors, even those without a legacy 32bit architecture attached, have instructions for manipulating 32bit data just fine. It is just that when your program needs to work with 64 bits at a time, it can do so more efficiently.
No, you're hosed when you use pointers, as you mention. Which is a LOT, no matter what language or programming style you use. (Not sure how it could be "fixable"...) For instance, your stack now must be twice as large because each stack slot is 8 bytes instead of 4. Your page tables only hold half as many entries. And so on. Basically everything takes up more space.
In the Java world, typically half the heap is pointers and the other half is ints. (The other types are negligible.) So you should expect your heap to grow by 25% and put that much more pressure on your memory system.
However, in practice, apps recompiled for AMD64 extensions tend to run a bit faster than IA32 apps on the same hardware, because the benefit of the extra registers outweighs the costs of bloated pointers.
Personally, I feel that a good bit of this waste and vulnerability is caused by Microsoft. Even more frustrating, as mentioned in repair #20, is that Microsoft has the resources to fix the problems. Microsoft is sitting on $50 billion in corporate cash reserves and could hire 100,000 American programmers with that money. Microsoft could build a bullet-proof OS, solve the virus problem completely, etc. But it chooses not to do that and, at least for now, seems to be largely immune to liability for all of these problems. Microsoft could make just one change - it could eliminate the need to reboot after installing many different types of software - and save the nation millions of man-hours per year. It could create one-click installation procedures and save millions more man-hours. It could build a system that automatically finds and loads drivers over the Internet and save millions more. And so on.
I think this fellow should try writing some software before he makes pronouncements like this.
I happen to agree that Microsoft (and practically everyone else) writes flaky software, and the situation would be improved if programmers were legally liable for their software (just like practically every other industry). However, the claims this guy is making are absurd. For instance, anyone who has read Fred Brooks knows you can't solve software problems by throwing 100,000 more programmers at the problem.
Brother, you need to get a grip. In the olden days, they used to do this thing called "planning ahead" where they would leave enough time in case traffic is bad. Most times they would get to the destination ten minutes early and find something to do.
Today people think their time is so extremely important that they can't bear to arrive some place before they absolutely need to. Well, I have news for you: when you arrive someplace, you are either early or late. There is no third choice, unless you can manage to arrive within planck time of the chosen moment.
Just get accustomed to being early for everything and life is less stressful. Yes, you might get one less thing done over the course of the day. (The horror!)
Hey, that's the best explanation I have ever read, except that the current definition of the second was adopted in 1967. 1972 was when the current system of leap seconds began.
Slashdot Mirror
Come on, give her a chance. How about this one, or this one.
Uh, you find this shocking?
Survivor Mars.
Those that modded this funny might want to consider that it appeared 12 minutes earlier here with the correct spelling of "Beowulf".
I think you meant "reprising" the role.
Fine, but then that has nothing to do with the gravity well.
What exactly did you think was keeping the asteroids up there?
The only such claim I ever saw said that Reiser had a higher CPU utilization, in percentage terms. But that's just what happens when you spend less time on I/O.
Imagine this benchmark scenario: Filesystem A takes 10 seconds and has 20% CPU usage. Filesystem B takes 2 seconds and has 90% cpu usage. Some would claim that Filesystem B is eating CPU cycles, but in fact it is consuming less processor time! (1.8 versus 2.0 CPU seconds.)
IIRC, the situation with ReiserFS is similar. It uses marginally more CPU time (maybe 10% or so) but the CPU utilization as a percentage seems much higher because it spends so much less time doing I/O.
Did you see the part where I said it was a joke? (Ok, maybe it's not funny. That's a different issue.)
Regarding your "acronym abuse" thing, it's a joke. It started with everyone saying "I am not a lawyer" before giving legal advice, which became "IANAL". Then, others started using it as a joke for any expert profession, like "IANARS (I Am Not A Rocket Scientist)".
Well, that's one way to look at it I guess. But if the security were only as "weak" as digital signature technology allows, that would be pretty damn strong. It would be much more like a padlock than an FBI warning.
I'm sorry, I should have been clearer. I'm not dumping on the users. I'm dumping on the developers who created this feature.
RTFA. This is not a brute-force attack. It's an inherent dumbness of their password scheme.
The real solution is a digital signature. Anyone to whom that is not obvious shouldn't be putting security measures in commercial products.
(I'm the lead developer on IBM's AMD64 JIT compiler porting effort.)
Simple: applications that benefit from being compiled for AMD64 will be. Applications that don't, won't. That's the beauty of backward compatibility.
Anyway, what "two pointers" are you referring to? The return address and frame pointer?
Sorry, I thought we were talking about AMD64. To paraphrase: in some code, memory will not be dominated by pointers. I'll grant you that.I think you're talking about scientific (loops-and-arrays) code that has been carefully optimized. I'll grant you that a 64-bit processor shouldn't be detrimental to that code. But there's a whack of OO-style code out there that is not dominated by arrays, and that code pays for 64 bits even if it doesn't need them.
In the Java world, typically half the heap is pointers and the other half is ints. (The other types are negligible.) So you should expect your heap to grow by 25% and put that much more pressure on your memory system.
However, in practice, apps recompiled for AMD64 extensions tend to run a bit faster than IA32 apps on the same hardware, because the benefit of the extra registers outweighs the costs of bloated pointers.
I happen to agree that Microsoft (and practically everyone else) writes flaky software, and the situation would be improved if programmers were legally liable for their software (just like practically every other industry). However, the claims this guy is making are absurd. For instance, anyone who has read Fred Brooks knows you can't solve software problems by throwing 100,000 more programmers at the problem.
I'm surprised you took the time to reply. I was really just trolling for dork comments. :-)
Today people think their time is so extremely important that they can't bear to arrive some place before they absolutely need to. Well, I have news for you: when you arrive someplace, you are either early or late. There is no third choice, unless you can manage to arrive within planck time of the chosen moment.
Just get accustomed to being early for everything and life is less stressful. Yes, you might get one less thing done over the course of the day. (The horror!)
Yeah, too many laws aim at the symptom rather than the problem itself.
-
A little Googling would find the correct quote: "No one who speaks German could be an evil man".
-
The xml syntax is "<simpsonism>", not "(simpsonism)".
-
You don't say "simpsonism" anyway. Everyone reading the site knows where the quote comes from, and if they don't, they can Google it.
-
Ditto for the smiley.
-
What the heck does this quote have to do with the rest of your post?
Sheesh.Hey, that's the best explanation I have ever read, except that the current definition of the second was adopted in 1967. 1972 was when the current system of leap seconds began.