I don't believe that people who promote illegal acts, whether advertising products or mere advocacy, are liable for the actions of those who take them up on their promotion.
Really? So you think that (say) if someone were to incite a bunch of high-school
kids to trash their local MacDonalds, said person should not bear some legal
responsibility? I think you would find that 99% of the adult population would
disagree with you!
The article addresses this. They say that the thrusters would be angled to miss the
asteroid. They also mention that this results in less efficient use of fuel.
And there is another way to do it. If you put two thrusters at the end of a boom that is
that is the same length as the asteroid's diameter (assuming it is spherical), you could
aim them so that they are nearly tangential to the asteroid's surface, resulting in more
efficient use of fuel. The downsides are 1) extra mass for the boom & dual thrusters, and
2) balancing the thrust so that the "tug" doesn't spin.
But this entire approach strikes me as overly complex. Given that the whole setup is only
going to exert less than 1lb of force on the asteroid, I'd have thought it was easier to
mount a gymballed 5lb thruster on the surface and fire it in synchrony with the asteroid's
rotation. You'd need to spread the force across a wide surface area, and take steps to
minimize vibration stresses, but that's just engineering... not "rocket science":-)
Take your pick. If you're worried about further intricacies, just write your own.
That is bad advice. If you write your own license, the chances are that a court would
decide that the roll-your-own license doesn't say what you want it to. Plus, anyone
wanting to use your software has to try to understand what your license actually means.
Ughh...
What is more cogent is can you justify evolution's position on the list? Can you justify any
of the scores on the list?
Scores like these are only meaningful if they
are derived by an objective, transparent and
justifiable process that is informed by factual
information.
Suppose that you air condition your closet to a nice and cool 20 degrees Celsius. Now suppose that it is a warm humid day, and you need to power cycle one of the servers.
You open the door to the closet. All the cold air rushes out, and is replaced by
warm humid air from the outside. Next thing that happens is that moisture in the
warm air starts to condense out on cool surfaces... like the casing of your computers.
Not good.
This is not a major problem in a typical computer room because opening and closing
the door only lets a relatively small proportion of the cold air out. But with a
closet, you are likely to lose a large proportion of the air... especially if you
have to leave the door open to give yourself room to move in the closet full of
servers. Even building an "air lock" won't help much.
If humidity is an issue, you may be better off fitting an exhaust fan.
I was informed that said optimizations have made it so that indexing an array with the [] operator is just as fast as using an incremented pointer. When the goal is maximum performance across multiple CPU architectures, can one always assume that this is true?
Honestly, there is no real justification for making any assumptions. It depends on
how good a particular C compiler is at generating code for a particular ISA.
Indeed, for some ISA's I'd expect a niave C compiler to generate FASTER code for
indexing an array than for incrementing a pointer. (I'm thinking of word addressed
ISAs, where a 'char*' has to be represented as a word pointer and a character offset.)
In the big picture, it probably doesn't make a great deal of difference to performance
which style you use. It might make 5-10% difference in a tight loop, but probably much
less across a large application. If the difference performance is significant, you
will get more benefit for your effort by:
finding better C compilers, or
using a profiler to find the real hotspots in the code and hand-optimizing them
for the hardware platforms that you really care about.
As other people have said, other issues than this are likely to have a greater bearing
on the overall performance of a typical application; e.g. data structures, algorithms, database design, etc.
I don't think so. The financial gains that Microsoft might get by sueing over patent infringement are dwarfed by the financial damage they would take if they did this. This is the kind of thing that would cause governments to start new anti-trust investigations. Besides, the people who they'd most like to sue (the open source players) wouldn't be able to pay significant damages to Microsoft, and they have very vocal friends.
IMO, the most effective thing that Microsoft can do is to use the implied threat of lawsuits to intimidate people / companies. Of course, this doesn't work so well if their bluff is called.
Actually, I think that Microsoft itself is in real danger over software patents. There could be 100's of software patents in the system that Microsoft is violating, and their healthy financial position makes them the ideal "mark" in a game of high stakes patent poker.
... if you want to insert a string that is too big for the field, MySQL will gladly suck it up with nary a peep (meanwhile, your data is trashed: truncate hell)
Starting from MySQL 5.0.2, there are configuration
variables that tell the database to reject invalid
field values. (At least that's what the online MySQL manual says...).
Leaving aside the impracticality of building a
lightweight containment vessel / radiation shield,
a car-sized nuclear reactor wouldn't explode with
much energy. The most likely explosion scenarios would be explosive failure of the pressure vessel
and / or secondary hydrogen explosion. The
energies involved would be orders of magnitude
less than a truck-load of high explosive.
The likelihood of a reactor (of any kind) going
off like an atom bomb is about zero. An atom
bomb requires enough fissile material to form
a critical mass to be brought together VERY
quickly. It is physically impossible for this
to happen in a reactor.
Before you go to the effort of changing all of
your teaching material, etc, etc, you need to
have a good handle on why students are
not taking the course. Are you sure it is the
programming language you are teaching that is
turning them off?
What you need to do (and this is hard!) is
to find out why students are turning away,
and try to address those issues.
We're killing innovation in the US with a suffocating tidal wave of patents and litigation, and completely de-emphasizing mathematics and sciences in the educational curriculums... putting up an appearance of being ahead in space flight can only last for a few more years. The foundation is rotting away.
I'm not saying they're idiots, they did the best with what they had.
Actually, I think you are implying this. After all, you state (without any citing evidence) that the TLB costs have "undoubtless gotten worse, not better".
Now I would have thought that Intel's engineers would understand the scaling issues, and would compensate for extra TLB contention (due to larger
working sets) and larger TLB miss penalties (pipeline stalls) by increasing TLB sizes and
other measures. On what basis do you think
that they "doubtless" failed?
The fact is that the computer industry is not ready to switch to using only type-safe programming languages. The computer industry has far too much invested in software written in C & C++ to change in the forseeable future. And certainly not for a mere 30% improvement in performance.
The current road that the industry is taking
for improved performance is to hardware support
for parallelism (e.g. multi-core chips, Intel's HT, Sun's CMT, IBM's Cell architecture),
multi-processor servers and processor farms.
You are a poser, and you know next to nothing about computers. Go to college, take an operating systems class, and actually try to learn the material.
Actually, I'm a Phd in Computer Science with
15+ years experience in R&D. I first came across
TLBs in about 1985 while running 4.1bsd on a VAX.
Recently, I've been doing a lot of Java work,
including developing an open source Java VM.
Actually, I'm thinking as a Java programmer. I
am fully aware that a good compiler for a HLL
will optimize away a lot of bounds checking
etcetera. But my key point was that you cannot
do all type safety checks at compile time...
like the original poster wanted.
As for NULL pointers, there's really no need for them at all if you have a serious type system. Recursive data structures are trivially dealt with if you have concepts like disjunctive types and pattern matching.
Under the covers, there always has to be some
way of representing "no object", and programs
have to implicitly or explicitly test for the
"no object" case. The test costs machine cycles.
In Java, it is a "null reference".
I'll grant your point about the evilness of
pointer arithmetic versus type safety and
optimisation, but I wasn't thinking along
those lines anyway. I was thinking more about
the hardware overhead of implementing virtual
addressing.
You just need part of the compiler to run on the client machine. Java, OCaml, etc.... They all do exactly this, and they work very well....
Oh please! The virtual machine is NOT
part of the compiler.
It is obvious to anyone who understands
the Java Virtual Machine that it handles
memory protection well enough to render
classical virtual memory support hardware unnecessary (with some caveats *). But it
is equally obvious that the Java Virtual
Machine has to do runtime checks
to implement memory protection. They cannot
be done by the compiler.
I will grant you that it is hard to be sure
whether the runtime overheads (i.e. extra instructions executed) for array bounds
checking, null pointer checking, etc in (say)
Java are more or less than the hidden overheads
(i.e. more or longer clock cycles) of classical
virtual addressing support. And this would be
a difficult experiment to perform...
(* The caveats are that the JVM implementation
including the JIT compiler, bytecode verifier,
and core native runtime libraries are all free
of bugs that cause/allow memory violations,
and that JNI is banned.)
Memory protection verifiably costs you something like 30% of your performance. That number was from a few years ago, it has doubless gotten worse, not better.
Why "doubtless"? Do you have any evidence for this, or do you just think that the Intel, AMD,
etc architects/chip designers are all idiots?
Memory protection through typesafety alone. Would give all computers a 30+% boost to performance if the security was handled by the compiler, and not the hardware.
This is not possible without crippling the programming language. For example:
You would have to eliminate arrays, because
it is impossible to do all array bounds
checking at compile time.
You would need to eliminate the concept
of a NULL pointer because checks for
NULL pointers cannot be always done at
compile time. This would make recursive
data structures problematical.
You would need to eliminate narrowing of
pointer types.
Hmmm... if light travels at 186,000 miles
per second, I wonder how fast I would go if I
managed to latch onto a photon as it passed
between my fingers?
Don't try this at home folks:-)
Slashdot Mirror
Really? So you think that (say) if someone were to incite a bunch of high-school kids to trash their local MacDonalds, said person should not bear some legal responsibility? I think you would find that 99% of the adult population would disagree with you!
And there is another way to do it. If you put two thrusters at the end of a boom that is that is the same length as the asteroid's diameter (assuming it is spherical), you could aim them so that they are nearly tangential to the asteroid's surface, resulting in more efficient use of fuel. The downsides are 1) extra mass for the boom & dual thrusters, and 2) balancing the thrust so that the "tug" doesn't spin.
But this entire approach strikes me as overly complex. Given that the whole setup is only going to exert less than 1lb of force on the asteroid, I'd have thought it was easier to mount a gymballed 5lb thruster on the surface and fire it in synchrony with the asteroid's rotation. You'd need to spread the force across a wide surface area, and take steps to minimize vibration stresses, but that's just engineering ... not "rocket science" :-)
That is bad advice. If you write your own license, the chances are that a court would decide that the roll-your-own license doesn't say what you want it to. Plus, anyone wanting to use your software has to try to understand what your license actually means. Ughh ...
What is more cogent is can you justify evolution's position on the list? Can you justify any of the scores on the list?
Scores like these are only meaningful if they are derived by an objective, transparent and justifiable process that is informed by factual information.
This is not a major problem in a typical computer room because opening and closing the door only lets a relatively small proportion of the cold air out. But with a closet, you are likely to lose a large proportion of the air ... especially if you
have to leave the door open to give yourself room to move in the closet full of
servers. Even building an "air lock" won't help much.
If humidity is an issue, you may be better off fitting an exhaust fan.
Honestly, there is no real justification for making any assumptions. It depends on how good a particular C compiler is at generating code for a particular ISA. Indeed, for some ISA's I'd expect a niave C compiler to generate FASTER code for indexing an array than for incrementing a pointer. (I'm thinking of word addressed ISAs, where a 'char*' has to be represented as a word pointer and a character offset.)
In the big picture, it probably doesn't make a great deal of difference to performance which style you use. It might make 5-10% difference in a tight loop, but probably much less across a large application. If the difference performance is significant, you will get more benefit for your effort by:
As other people have said, other issues than this are likely to have a greater bearing on the overall performance of a typical application; e.g. data structures, algorithms, database design, etc.
IMO, the most effective thing that Microsoft can do is to use the implied threat of lawsuits to intimidate people / companies. Of course, this doesn't work so well if their bluff is called.
Actually, I think that Microsoft itself is in real danger over software patents. There could be 100's of software patents in the system that Microsoft is violating, and their healthy financial position makes them the ideal "mark" in a game of high stakes patent poker.
Why stop there? You could make it EVEN MORE secure by super-gluing the keys and the mouse buttons. :-)
The likelihood of a reactor (of any kind) going off like an atom bomb is about zero. An atom bomb requires enough fissile material to form a critical mass to be brought together VERY quickly. It is physically impossible for this to happen in a reactor.
What you need to do (and this is hard!) is to find out why students are turning away, and try to address those issues.
Ooops! I forgot, we were in conspiracy theory mode.
And if the nanotubes were in solution, they wouldn't be nanotubes any more.
Face facts ... you're all DOOMED. :-)
Actually, I think you are implying this. After all, you state (without any citing evidence) that the TLB costs have "undoubtless gotten worse, not better".
Now I would have thought that Intel's engineers would understand the scaling issues, and would compensate for extra TLB contention (due to larger working sets) and larger TLB miss penalties (pipeline stalls) by increasing TLB sizes and other measures. On what basis do you think that they "doubtless" failed?
The fact is that the computer industry is not ready to switch to using only type-safe programming languages. The computer industry has far too much invested in software written in C & C++ to change in the forseeable future. And certainly not for a mere 30% improvement in performance.
The current road that the industry is taking for improved performance is to hardware support for parallelism (e.g. multi-core chips, Intel's HT, Sun's CMT, IBM's Cell architecture), multi-processor servers and processor farms.
Actually, I'm a Phd in Computer Science with 15+ years experience in R&D. I first came across TLBs in about 1985 while running 4.1bsd on a VAX. Recently, I've been doing a lot of Java work, including developing an open source Java VM.
What are your credentials Junior?
As for NULL pointers, there's really no need for them at all if you have a serious type system. Recursive data structures are trivially dealt with if you have concepts like disjunctive types and pattern matching.
Under the covers, there always has to be some way of representing "no object", and programs have to implicitly or explicitly test for the "no object" case. The test costs machine cycles. In Java, it is a "null reference".
I'll grant your point about the evilness of pointer arithmetic versus type safety and optimisation, but I wasn't thinking along those lines anyway. I was thinking more about the hardware overhead of implementing virtual addressing.
Please reread the grandparent article. He expects all type safety checks to be done at compile time.
Oh please! The virtual machine is NOT part of the compiler.
It is obvious to anyone who understands the Java Virtual Machine that it handles memory protection well enough to render classical virtual memory support hardware unnecessary (with some caveats *). But it is equally obvious that the Java Virtual Machine has to do runtime checks to implement memory protection. They cannot be done by the compiler.
I will grant you that it is hard to be sure whether the runtime overheads (i.e. extra instructions executed) for array bounds checking, null pointer checking, etc in (say) Java are more or less than the hidden overheads (i.e. more or longer clock cycles) of classical virtual addressing support. And this would be a difficult experiment to perform ...
(* The caveats are that the JVM implementation including the JIT compiler, bytecode verifier, and core native runtime libraries are all free of bugs that cause/allow memory violations, and that JNI is banned.) Memory protection verifiably costs you something like 30% of your performance. That number was from a few years ago, it has doubless gotten worse, not better.
Why "doubtless"? Do you have any evidence for this, or do you just think that the Intel, AMD, etc architects/chip designers are all idiots?
This is not possible without crippling the programming language. For example:
- You would have to eliminate arrays, because
it is impossible to do all array bounds
checking at compile time.
- You would need to eliminate the concept
of a NULL pointer because checks for
NULL pointers cannot be always done at
compile time. This would make recursive
data structures problematical.
- You would need to eliminate narrowing of
pointer types.
and so on.Hmmm ... if light travels at 186,000 miles
per second, I wonder how fast I would go if I
managed to latch onto a photon as it passed
between my fingers?
Don't try this at home folks :-)
Yes ... fantastically
... unless you were insinuating that a viola is an instrument of terror rather than an instrument of music.
He probably has as much evidence as the CIA had that Sadam Hussein had weapons of mass destruction. And no, I'm not just being cynical ...
Obviously, it is seagull poo on the camera lens.