It's too bad someone has to say this every time some smartass makes the same old, tired point that "Moore's Law is not a law". I wish the moderators would get the hint and mod those down as redundant.
I have only been to San Antonio once, but IIRC they had an "estimated time to exit X" display on the highway signs. Traffic information just couldn't be any more relevant and useful than that.
I find, "Such an adventure would resonate with a world beset by wars and woes" deadly condescending. You know what would resonate with the world? Getting rid of some of those "wars and woes." Think a cure for AIDS, or even malaria.
Now that is condescending. I applaud all efforts to reduce/eliminate/ameliorate war and disease, but if that becomes mankind's one and only goal, we will stagnate. What is the point of concentrating on extending the quantity and duration of human life to the exclusion of all that makes life worth living?
How far would you take this policy? Should people stop making movies because the resources would be better spend fighting AIDS? How about music? Should we stop teaching history because history teachers would better spend their time fighting AIDS? Besides, what was the last contribution you made in the fight against AIDS?
Our greatest strength is our diversity. Some people work on curing AIDS while others try to build a better spacecraft. To stigmatize the latter is unfair and shortsighted.
Apollo stands as one of mankind's greatest achievements. There's no need to one-up it...
The internal logic of this statement escapes me. How can you consider the Apollo mission to be such a great achievement, and yet claim that it is not worth pursuing the exact same kind of achievement today? Can you honestly (honestly, now) tell me that you would not have used the same arguments during the 1960s to condemn the Apollo mission itself?
Let me put this in perspective. Imagine scaling down the universe so the nearest star is at the location the moon currently occupies. How far do you think the scaled-down moon would be? Do you think it would be as far as San Francisco from Los Angeles? No, too far. Perhaps it would be a mile or two? Still too far. How about one city block?
In fact, the moon would be less than 4 meters away. So, to say that going to the moon makes further space travel unnecessary would be like saying that travelling from your bedroom to your kitchen made the Appolo mission redundant. The technological advances required to reach the stars will be as different from Apollo as the Saturn rocket is from your two feet.
...and there's no need to live in space. We haven't conquered living on Earth.
What an absurd, vacuous sound-bite. Would you stop launching rockets until there are 10 billion happy, friendly, healthy people living in peace and brotherhood, holding hands and singing songs in each others' languages, when finally one of them says "well, we have conquered living on earth; let's start thinking about space travel"?
No? Then what is your criterion? When exactly will you be satisfied that we have "conquered living on Earth"? And how do you justify the notion that this is a prerequisite to space exploration? You didn't address that at all.
I guess you're right. Concatenated words in Java typically use camelCase, so it should really be "forEach", in which case it is very likely to collide with existing method names. (Note, though, that "in" itself may still collide; perhaps that's why they chose the colon.)
I don't understand why they didn't use the same syntax as C#: "foreach(String s in c)". Much clearer than the new Java syntax.
Re:But what I am rellay looking forward to...
on
KDE 3.1 Released
·
· Score: 1
Of course, this means that the processes stay alive and continue to eat RAM while they are, but if you don't use Konq for a while they'll get swapped out to VM. It's still faster than launching a process cold, though.
I wonder if you could take a memory snapshot of a running process, and save that to disk. Make it part of the distro. Then to start Konqueror, load that image. It's basically the same as the VM swapping thing, but without any initial slow startup.
Seems to me that this could be a generally useful mechanism.
I thought the story of this one was cool, but the direction was really amateurish. First, they could probably have trimmed out 30 minutes just by removing the pauses in the dialogue. I have never studied drama, yet even I know that's the first thing you learn about dialogue: remove the "beats", or pauses between lines, to make it look more natural.
The clone-of-Picard thing was cool, and it looks to me like the script handled it really well, but the execution tanked. Between the dinner they shared, the conversation in the ready room, etc., there was obviously supposed to be some conflict within Shinzon about fighting with his own "brother" (ie. clone). But it ended up just being really limp and boring because of the poor timing of the director.
The battle at the end had a very naval feel to it that I really liked. However, like everything else, it was TOO SLOW. Furthermore, Shinzon was headed toward Earth, so they had the perfect excuse to have that battle with Earth as the backdrop. Instead, they had it in the middle of space, next to some kind of nebula. How dull.
Finally, the commercials looked kind of dumb. I went to see it because I like movies---even a mediocre movie is fun to see---but I was surprised how interesting the story and the back-story were, because there was no hint of them in the ads.
First, I was saying that people working on OSS are less likely than professionals to hang around a project when it stops being fun. I think the poor state of the economy makes professionals that much more likely to stick with a job they don't like, which makes my point that much stronger. Do you disagree?
Second, I expressed no opinion whatsoever about Mr. Dillon's ego. (In fact, I explicitly stated that I have no such opinion.) I don't know the guy, and I must confess I had no idea who he was before this Slashdot article, so I am in no opinion to judge the man's ego.
As for criticizing someone else's work---yep, I have had at least one situation where I handled that poorly. What's your point?
I can't speak about Matt Dillon, but I agree with your assessment. It's important to be respectful of others in Open Source software development, because if you're not, they're unlikely to stick around just for the paycheque.
They went bankrupt because they went into debt during a boom. That's just stupid, but it was typical during the dot-com era.
Save money when you have it, and spend it when you don't. That's how you ride out a recession, but some companies (and most individuals) do just the opposite: they spend money when they have lots of it, and then valiantly try to save money when money is tight. That's a recipe for bankruptcy.
You're right about the longevity of temporary solutions. I just wish the answer were a development process that encouraged regular code-cleanup efforts, rather than simply never committing temporary solutions.
I'm not sure I follow your comments regarding the JIT. I think you're thinking of a Java interpreter, not a JIT compiler. Once the code is compiled, it's no longer java. It accesses memory and slings data just like any other assembly code, so I'm not sure what your point is there.
Also, as I said in my previous post, the JIT issue is not a one-time compile-then-execute thing. I agree that such a scenario could probably just change permissions after compilation is finished. The issue I'm referring to is that jitted code must be self-modifying to be efficient. Let me explain one scenario...
Most virtual methods are actually monomorphic at runtime (meaning that they only have a single target method despite being virtual). Thus, a crucial optimization is called "devirtualization" where you optimistically assume that all methods will be monomorphic until you have evidence to the contrary. This allows you to make direct calls to those methods, rather than more expensive indirect calls. More importantly, you may be able to inline the target method and get huge benefits in later optimizations. However, if your optimism turns out to be wrong, the code must be able to heal itself to undo these falsified assumptions in order to continue to run correctly.
Your arrangement would require two otherwise unnecessary mmaps to allow this healing to occur, which would hurt performance.
I think an OS has no business trying to protect an application from itself; only from other applications. If the OS prevents an application from doing something "just in case" it might hurt itself, then some applications will suffer.
Having said that, I guess there's no harm in making stacks non-executable by default, and applications could make their stacks executable if they want. But if you're suggesting that readable-executable memory should be banned by the OS for security reasons, then I object to that for performance reasons.
It's not obvious to me that the JIT compiler needs to share the same view of memory as the process for which it compiles.
Are you assuming that a JIT and the executing program are in two separate processes? I'm not sure that's very practical. I suppose it's possible, but I don't know of a JIT compiler that works this way.
Anyway, jitted code must be self-modifying to deal efficiently with newly-loaded classes. You can't do that without writeable and executable pages. (Two trips to the kernel every time you want to insert a jump around a devirtualized call site would be death.)
Non-writable stacks don't solve the buffer overflow problem. Programs with buffer overflow exploits are buggy and should be fixed. A non-executable stack just detects the problem, which is fine if that's what you want, but it's no solution.
And your taxonomy of memory permissions is naive.
Memory with no permissions is used in shared-memory clusters to make memory temporarily inaccessible so the memory sharing system can detect subsequent accesses and propagate the appropriate data. This must be done on a page-by-page basis. (Whether it'd done by priviledge levels or whatever is an implentation detail of mmap.)
Writable-executable memory is essential for Java Just-In-Time (JIT) compilers. To achieve decent performance, jitted code must be self-modifying to deal with newly loaded classes.
Even write-only memory may be useful for some kinds of interprocess communication.
Your idea of separating return values and data on the stack has some merit, but I reiterate: buffer overflow attacks are bugs that should be fixed. Systems to detect them and reduce damage are good, but they are not a solution.
What a process does with its own memory is its own business. Programs that allow stack-smashing attacks are broken and should be fixed, period.
Having said that, there are lots of buggy programs, and a lot of them run with elevated priviledges. I wonder if it would make sense to write-protect the stack, and then email a core file to the program's maintainer when an attempt is made to execute the stack.:-)
I agree that Duff's Device is clever, but I'm puzzled as to why he was surprised that it worked.
I'd be surprised too, because the loop and switch constructs are not properly nested: parts of the switch construct are inside the nested loop. That seems bizarre until you stop thinking of the switch as a construct and start thinking of it as a series of labels; and that is an unusual step. (I'm hard-pressed to think of another language that would accept code like that.)
Slashdot Mirror
It's too bad someone has to say this every time some smartass makes the same old, tired point that "Moore's Law is not a law". I wish the moderators would get the hint and mod those down as redundant.
I have only been to San Antonio once, but IIRC they had an "estimated time to exit X" display on the highway signs. Traffic information just couldn't be any more relevant and useful than that.
Um, time to take another look at the first Simpsons episodes. They sucked compared to how the show evolved a few years later.
Not always.
Who in the world thinks they need to learn all the libraries before they can start programming in Java??
How far would you take this policy? Should people stop making movies because the resources would be better spend fighting AIDS? How about music? Should we stop teaching history because history teachers would better spend their time fighting AIDS? Besides, what was the last contribution you made in the fight against AIDS?
Our greatest strength is our diversity. Some people work on curing AIDS while others try to build a better spacecraft. To stigmatize the latter is unfair and shortsighted.
The internal logic of this statement escapes me. How can you consider the Apollo mission to be such a great achievement, and yet claim that it is not worth pursuing the exact same kind of achievement today? Can you honestly (honestly, now) tell me that you would not have used the same arguments during the 1960s to condemn the Apollo mission itself?Let me put this in perspective. Imagine scaling down the universe so the nearest star is at the location the moon currently occupies. How far do you think the scaled-down moon would be? Do you think it would be as far as San Francisco from Los Angeles? No, too far. Perhaps it would be a mile or two? Still too far. How about one city block?
In fact, the moon would be less than 4 meters away. So, to say that going to the moon makes further space travel unnecessary would be like saying that travelling from your bedroom to your kitchen made the Appolo mission redundant. The technological advances required to reach the stars will be as different from Apollo as the Saturn rocket is from your two feet.
What an absurd, vacuous sound-bite. Would you stop launching rockets until there are 10 billion happy, friendly, healthy people living in peace and brotherhood, holding hands and singing songs in each others' languages, when finally one of them says "well, we have conquered living on earth; let's start thinking about space travel"?No? Then what is your criterion? When exactly will you be satisfied that we have "conquered living on Earth"? And how do you justify the notion that this is a prerequisite to space exploration? You didn't address that at all.
I guess you're right. Concatenated words in Java typically use camelCase, so it should really be "forEach", in which case it is very likely to collide with existing method names. (Note, though, that "in" itself may still collide; perhaps that's why they chose the colon.)
I don't understand why they didn't use the same syntax as C#: "foreach(String s in c)". Much clearer than the new Java syntax.
Seems to me that this could be a generally useful mechanism.
I thought the story of this one was cool, but the direction was really amateurish. First, they could probably have trimmed out 30 minutes just by removing the pauses in the dialogue. I have never studied drama, yet even I know that's the first thing you learn about dialogue: remove the "beats", or pauses between lines, to make it look more natural.
The clone-of-Picard thing was cool, and it looks to me like the script handled it really well, but the execution tanked. Between the dinner they shared, the conversation in the ready room, etc., there was obviously supposed to be some conflict within Shinzon about fighting with his own "brother" (ie. clone). But it ended up just being really limp and boring because of the poor timing of the director.
The battle at the end had a very naval feel to it that I really liked. However, like everything else, it was TOO SLOW. Furthermore, Shinzon was headed toward Earth, so they had the perfect excuse to have that battle with Earth as the backdrop. Instead, they had it in the middle of space, next to some kind of nebula. How dull.
Finally, the commercials looked kind of dumb. I went to see it because I like movies---even a mediocre movie is fun to see---but I was surprised how interesting the story and the back-story were, because there was no hint of them in the ads.
First, I was saying that people working on OSS are less likely than professionals to hang around a project when it stops being fun. I think the poor state of the economy makes professionals that much more likely to stick with a job they don't like, which makes my point that much stronger. Do you disagree?
Second, I expressed no opinion whatsoever about Mr. Dillon's ego. (In fact, I explicitly stated that I have no such opinion.) I don't know the guy, and I must confess I had no idea who he was before this Slashdot article, so I am in no opinion to judge the man's ego.
As for criticizing someone else's work---yep, I have had at least one situation where I handled that poorly. What's your point?
I can't speak about Matt Dillon, but I agree with your assessment. It's important to be respectful of others in Open Source software development, because if you're not, they're unlikely to stick around just for the paycheque.
Save money when you have it, and spend it when you don't. That's how you ride out a recession, but some companies (and most individuals) do just the opposite: they spend money when they have lots of it, and then valiantly try to save money when money is tight. That's a recipe for bankruptcy.
You're right about the longevity of temporary solutions. I just wish the answer were a development process that encouraged regular code-cleanup efforts, rather than simply never committing temporary solutions.
Also, as I said in my previous post, the JIT issue is not a one-time compile-then-execute thing. I agree that such a scenario could probably just change permissions after compilation is finished. The issue I'm referring to is that jitted code must be self-modifying to be efficient. Let me explain one scenario...
Most virtual methods are actually monomorphic at runtime (meaning that they only have a single target method despite being virtual). Thus, a crucial optimization is called "devirtualization" where you optimistically assume that all methods will be monomorphic until you have evidence to the contrary. This allows you to make direct calls to those methods, rather than more expensive indirect calls. More importantly, you may be able to inline the target method and get huge benefits in later optimizations. However, if your optimism turns out to be wrong, the code must be able to heal itself to undo these falsified assumptions in order to continue to run correctly.
Your arrangement would require two otherwise unnecessary mmaps to allow this healing to occur, which would hurt performance.
I think an OS has no business trying to protect an application from itself; only from other applications. If the OS prevents an application from doing something "just in case" it might hurt itself, then some applications will suffer.
Having said that, I guess there's no harm in making stacks non-executable by default, and applications could make their stacks executable if they want. But if you're suggesting that readable-executable memory should be banned by the OS for security reasons, then I object to that for performance reasons.
Anyway, jitted code must be self-modifying to deal efficiently with newly-loaded classes. You can't do that without writeable and executable pages. (Two trips to the kernel every time you want to insert a jump around a devirtualized call site would be death.)
And your taxonomy of memory permissions is naive.
-
Memory with no permissions is used in shared-memory clusters to make memory temporarily inaccessible so the memory sharing system can detect subsequent accesses and propagate the appropriate data. This must be done on a page-by-page basis. (Whether it'd done by priviledge levels or whatever is an implentation detail of mmap.)
-
Writable-executable memory is essential for Java Just-In-Time (JIT) compilers. To achieve decent performance, jitted code must be self-modifying to deal with newly loaded classes.
-
Even write-only memory may be useful for some kinds of interprocess communication.
Your idea of separating return values and data on the stack has some merit, but I reiterate: buffer overflow attacks are bugs that should be fixed. Systems to detect them and reduce damage are good, but they are not a solution.Having said that, there are lots of buggy programs, and a lot of them run with elevated priviledges. I wonder if it would make sense to write-protect the stack, and then email a core file to the program's maintainer when an attempt is made to execute the stack. :-)
Have you considered going for most parentheses in a single sentence? I think you have a contender there.
If there were a "-1: Obvious" moderation, I would have applied it to this post.