This, my friends, is a troll. Any time any space program is mentioned, someone says they'd be better off giving the money back to the citizens, or curing cancer or something. We have rebutted this any number of times, yet it gets posted again. That makes the author either naive or a troll.
If you have the energy to post a rebuttal, have fun. I've done it too many times already.
These countries will all go and colonize other bodies in the solar system, and then the colonies will rebel and become sovereign nations. So the flag that was painted on the side of the rocket that got them there is pretty much irrelevant.
Yup, I know what you wrote is the part in italics. Sorry for the confusion. My remark was meant for Cliff.
Incidentally, a friend of mine just told me last week that he read a study (and if that's not authoratative, I don't know what is) that said IT spending is inversely related to employee productivity. That's right: the more a company spends on IT, the less productive its employees are. Of course, I have no reference.
Yes, but it still fails on data that's already compressed. According to the paper (as opposed to the abstract), both PGP and GPG disable compression on data that's already compressed, thus allowing the attack to succeed.
This guy is so full of himself, I don't know how he could be taken seriously. He wants us to think he's David for MS's Goliath, and he has just discovered his sling. Well, I'll believe it when I see it.
If you have the patience to read through his smarmy instructions on how to reproduce the defect, you'll discover that he has indeed hit upon a rather serious security flaw. He then proceeds to give three strawmen--er, I mean possible solutions to the problem--and argues that since these three things can't fix it, nothing can. Well, I'm not convinced.
What if Windows' messaging were changed so that certain messages that are considered insecure (like WM_TIMER) can only be sent to windows owned by the sending process? What if the text inside an edit control were held in some piece of memory with no execute priviledges? These are two things that, I think, could solve this problem immediately, with little inconvenience to users.
Also, check out this guy's pompous letter to Microsoft, in which he states, "Since Microsoft already know about this issue, and any of your
programmers will be able to replicate and verify the issue in less than
an hour given the information in my advisory, I'm not prepared to wait
very long." Clearly this, er, fellow has no experience in large software companies. Even good software has perhaps hundreds of defects outstanding at any given moment, at various levels of urgency, competing for developers' attention. Apparently he either thinks he's so important that he can jump the queue, or else he imagines that these armies of developers are sitting idly at their desks waiting for people like him to give them something to do.
Well, that's enough ranting. The upshot of it is, I wouldn't be too woried. He has not done a Jenga on Windows.
How can you write a Non-OO program in a Pure-OO language? Cause, you see, it's not possible. You can write a program that isn't in the OO style that you think of when you think of OO. But you can't write a program that has data that isn't an "object" in a Pure-OO language.
What does this mean exactly?
If a program is not in the OO style; if it doesn't decompose a problem by data abstractions; if it doesn't solve problems using encapsulation and polymorphism; then just what exactly do you mean when you say that data is an "object"?
(I don't mean that question rhetorically--if you have an answer, I'd like to hear it.)
If you believe you can't write non-OO programs in an OO language, then I envy you the coworkers you must have had.:-)
Suggesting that we get rid of primatives severly hurts your credability.
Ad-hominem arguments hurt your credibility more. He posted lots of fairly convincing reasons that primitives are not necessary. Do you have any actual reasons for thinking they are?
It's a matter of principle. It's the kernel's job to protect programs from each other, not from themselves. To remove execute permission from the stack would be the start of a slippery slope, whereby the kernel starts to coddle buggy programs, resulting in a false sense of security.
The problem, of course, occurs when a program trusted with security responsibilities contains a bug. In such cases, the answer is to fix the bug. This is not, and should not be, the kernel's responsibility.
Having said that, if you want to apply the non-executable stack patch because you don't trust your "trusted" programs, go ahead.:-)
My point is that there is no GC algorithm which you can write (ahead of time) for a given application that is better than the GC implementation I can custom-write for my application.
Agreed. My point is that malloc+free is rarely the ideal answer. In fact, I'd be willing to wager that most applications don't get any performance benefit from malloc+free versus a well-tuned conservative GC.
More than that, a program written for GC (i.e., without any free() or delete calls) cannot be ported to a system which doesn't support GC.
Amen. I just spent several months trying to do just that.
This is entirely out of context. Linus says that there are some problems in Linux related to implementing certain 64-bit things in certain ways, partly because of gcc bugs, and so he said the equivalent of "let's hope x86-64 wins because then we don't have to think about it".
I wouldn't take this particular quote to be his definitive statement of preference for x86-64 over IA-64.
Re:Cool project resulting from a big problem?
on
RPM Dependency Graph
·
· Score: 2
What is the problem you're trying to solve? Who cares about complicated dependencies, so long as they are minimal and acyclic?
You really really wouldn't want to write an operating system with C++, much less with GC.
Bull.
Be was written in C++, and so is K42, IBM's next big massively scalable Linux-compatible kernel. Some of the smartest people I have ever met work on K42, and these guys know C++.
Also, GC doesn't necessarily add any overhead to programs: it depends on memory usage patterns, but clearly, being forced to free everything chunk-by-chunk as it's no longer needed can't always be the most efficient policy. (Otherwise, why do program call stacks use special-purpose storage management instead of the heap?)
Having said that, it is true that a conservative collector is not suitable for all memory allocation needs.
If something is not quite destroyed, you could say it suffered "near-total destruction". If it were very quiet, perhaps it emits "near-inaudible noises". Someone who is not yet adult could be a "near-adult". Thus, if something didn't hit us, we may experience a "near-hit".
However, note the hyphenation in these phrases. Let's consider what happens when you remove the hyphen...
If a baseball player hits the ball hard, that could be a "hard hit". If a record sells very quickly, it could be an "instant hit". In the first case, we have a hit which is hard; in the second, it's a hit which is instant. Thus, can't we expect that a "near hit" would be a hit that is near (ie. close)? Since this isn't a hit at all, it can't be a "near hit".
Thus, I vote for "near miss". (Or, if you prefer, "near-hit".)
Slashdot Mirror
If you have the energy to post a rebuttal, have fun. I've done it too many times already.
On the moon, I guess it's a selenological survey.
These countries will all go and colonize other bodies in the solar system, and then the colonies will rebel and become sovereign nations. So the flag that was painted on the side of the rocket that got them there is pretty much irrelevant.
Incidentally, a friend of mine just told me last week that he read a study (and if that's not authoratative, I don't know what is) that said IT spending is inversely related to employee productivity. That's right: the more a company spends on IT, the less productive its employees are. Of course, I have no reference.
Yes, but it still fails on data that's already compressed. According to the paper (as opposed to the abstract), both PGP and GPG disable compression on data that's already compressed, thus allowing the attack to succeed.
There's no such thing as a "cost benefit". The phrase you're looking for is "cost-benefit analysis" which compares costs against benefits.
I'm not sure how you came to that conclusion. Check out section 5 of the paper.
Er, what does this have to do with what I said? The digits of 37 are not divisible by 5.
Not to mention that if all the digits in a number are divisible by n, then the whole number is also divisible by n.
'Nuff said.
If you have the patience to read through his smarmy instructions on how to reproduce the defect, you'll discover that he has indeed hit upon a rather serious security flaw. He then proceeds to give three strawmen--er, I mean possible solutions to the problem--and argues that since these three things can't fix it, nothing can. Well, I'm not convinced.
What if Windows' messaging were changed so that certain messages that are considered insecure (like WM_TIMER) can only be sent to windows owned by the sending process? What if the text inside an edit control were held in some piece of memory with no execute priviledges? These are two things that, I think, could solve this problem immediately, with little inconvenience to users.
Also, check out this guy's pompous letter to Microsoft, in which he states, "Since Microsoft already know about this issue, and any of your programmers will be able to replicate and verify the issue in less than an hour given the information in my advisory, I'm not prepared to wait very long." Clearly this, er, fellow has no experience in large software companies. Even good software has perhaps hundreds of defects outstanding at any given moment, at various levels of urgency, competing for developers' attention. Apparently he either thinks he's so important that he can jump the queue, or else he imagines that these armies of developers are sitting idly at their desks waiting for people like him to give them something to do.
Well, that's enough ranting. The upshot of it is, I wouldn't be too woried. He has not done a Jenga on Windows.
There's a lot more to classes than what you quoted; yet even by those meagre criteria, final classes still qualify.
If a program is not in the OO style; if it doesn't decompose a problem by data abstractions; if it doesn't solve problems using encapsulation and polymorphism; then just what exactly do you mean when you say that data is an "object"?
(I don't mean that question rhetorically--if you have an answer, I'd like to hear it.)
If you believe you can't write non-OO programs in an OO language, then I envy you the coworkers you must have had. :-)
Actually, it's the opposite of the Magic Eye technique. This is crosseyed, while Magic Eye is walleyed.
The problem, of course, occurs when a program trusted with security responsibilities contains a bug. In such cases, the answer is to fix the bug. This is not, and should not be, the kernel's responsibility.
Having said that, if you want to apply the non-executable stack patch because you don't trust your "trusted" programs, go ahead. :-)
You, my friend, are in dire need of a sense of humour.
I wouldn't take this particular quote to be his definitive statement of preference for x86-64 over IA-64.
What is the problem you're trying to solve? Who cares about complicated dependencies, so long as they are minimal and acyclic?
Be was written in C++, and so is K42, IBM's next big massively scalable Linux-compatible kernel. Some of the smartest people I have ever met work on K42, and these guys know C++.
Also, GC doesn't necessarily add any overhead to programs: it depends on memory usage patterns, but clearly, being forced to free everything chunk-by-chunk as it's no longer needed can't always be the most efficient policy. (Otherwise, why do program call stacks use special-purpose storage management instead of the heap?)
Having said that, it is true that a conservative collector is not suitable for all memory allocation needs.
Well, what do you know... By the time I read it, the headline is "Gates admits 'misstep' in parts of .NET launch".
That would be closer to 1/5.
If something is not quite destroyed, you could say it suffered "near-total destruction". If it were very quiet, perhaps it emits "near-inaudible noises". Someone who is not yet adult could be a "near-adult". Thus, if something didn't hit us, we may experience a "near-hit".
However, note the hyphenation in these phrases. Let's consider what happens when you remove the hyphen...
If a baseball player hits the ball hard, that could be a "hard hit". If a record sells very quickly, it could be an "instant hit". In the first case, we have a hit which is hard; in the second, it's a hit which is instant. Thus, can't we expect that a "near hit" would be a hit that is near (ie. close)? Since this isn't a hit at all, it can't be a "near hit".
Thus, I vote for "near miss". (Or, if you prefer, "near-hit".)