"The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. Blessed is he who in the name of charity and good will shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who attempt to poison and destroy my brothers. And you will know my name is the Lord when I lay my vengeance upon thee."
Christ, dude, there's no reason to get nasty. If you don't agree with me, fine, argue with me. Calling me names, though? That's just kinda childish, isn't it?
What you said in this post is basically unarguable. You said, essentially, that performance isn't the only important factor. Um... duh. But that's not what you originally said. You originally said that web servers are not expensive, which missed the point entirely. (If you can't solve your scalability problem by throwing more hardware at it, then the cost of the hardware is immaterial.) Then you said that trading performance for initial development time makes sense because you can buy more hardware for the money that you would have spent on software engineering. Which also misses the point, because you can find yourself in a situation where you saved money on development in the early stages, but you have to spend more money on development now to solve a scalability problem that can't be solved by buying more hardware. In that case, you save money on development at the beginning, but spend even more money on it later, which does not make sense for the bottom line.
So... how exactly am I ignoring "every fucking thing" you've said, and/or adding "all sorts of shit" that you didn't say?
Yes, some of his objections are certainly valid. If I ever implied that I think otherwise, then I misspoke. But saying "they lied!" as Neumann did is just going too far.
This is evil how? Sounds like good business to me. If you don't like it, compete with it.
What's that? You can't compete with it? Then maybe Home Depot is just better at what they do than you are. That's the nature of a free market; the strongest companies bubble up to the top.
Read the article a second time, critically this time. When he says things like "THAT is clearly a lie," do you really think he's literally correct? Of course he isn't. He says they "lied," but what he really means is, "I disagree with this interpretation of the facts."
"Lie" has a very specific meaning: it means deliberately and knowingly saying something contrary to the truth. There's no evidence that anybody involved with this lied. There are different interpretations of the facts-- obviously-- but that's not the same as a lie.
I reiterate my point: don't jump to conclusions. And I add a second point: use your brain as you read.
Its not entirely clear to me from the articles that the performance gap is very large, or if it exists, or if it does, who is in the lead.
I agree completely, and I think I would have avoided some confusion if I'd made that more clear in the first place. The point is not that either J2EE or.NET is better; the point is that it matters which one is better, if in fact one of them is.
Now, both J2EE and.NET are complex frameworks. It's entirely possible, though maybe not probable, that one or both of them will have at least one significant flaw that's not immediately obvious. Given that it's possible, I think it's worthwhile to do this kind of testing to see if it's true. The argument that performance doesn't matter isn't really a very good one, in my opinion.
I think that its safe to argue that for a given application, a proper implementation in.NET or J2EE would have nearly equal performance
Unfortunately I'm not sure it's safe to say that. Until more side-by-side testing is done, it's not reasonable at all to say that.NET and J2EE are equivalent. They may be, they may not be. We don't know yet.
I feel confident saying that as long as the percieved performance gap is small, or at least manageable, performance will not drive decision making.
But, as I've pointed out elsewhere, enterprise applications are different from other kinds of applications. While desktop applications have basically unchanging user requirements, enterprise applications will be called on to handle ever-increasing user requirements. (Today we need to be able to handle 100 concurrent users of the system. In six months, we need to be able to handle 100,000 concurrent users. Can we do that without making any code changes to the application, or will we have to rewrite as we discover performance bottlenecks?) Because enterprise apps have to scale, the choice of tools and frameworks you use at the beginning is a much more important decision, if you want to avoid painting yourself into a corner.
Ohhhhkay. You're not following the reasoning here. You invest $X in your server hardware. In order to save money, you spend more on hardware so you can use a software framework that doesn't perform or scale as well but for which the developers can write the application faster. You deploy the application-- which had a fixed development cost of $Y-- on the server, which had a fixed capital cost of $X.
Six months later, your customers start going elsewhere because your web application is too slow. It's not scaling under load the way it needs to. That's okay, because you can just invest in more hardware, right?
Wrong. If the application or the application framework doesn't scale, then more hardware won't help. You have to go back to the developers again (at a cost of $Z, which as you point out is significantly more expensive than simply buying new hardware) so they can optimize or refactor or, in the worst case, just rewrite whole sections from scratch to improve scalability.
If-- and I'm not saying this is the case-- the J2EE framework or the.NET framework is fundamentally flawed in some way, not knowing it and not acting on that information at the beginning of your project can cost you a fortune later on. How can we tell if J2EE or.NET or whatever else is flawed? Test it. Do side-by-side performance comparisons to tell us how the two frameworks compare in terms of reliability and scalability. There's really no other way to judge which of them is a better long-term investment.
In other words, mosch, if you cut two weeks off of your project now, but have to invest two more months in it a year from now, your net cost is higher than if you took two extra weeks and used the better framework in the first place.
Of course, the whole point is kind of moot because in this case there's no conclusive evidence for either J2EE or.NET being a better choice. But that doesn't mean that benchmarks and comparisons are meaningless.
Dude, do you understand that we're not talking about serving up static web pages here? We're talking about enterprise applications. These sorts of things are (1) extremely important to the companies that run them, and (2) very hard to cluster-ize. If your bank uses an enterprise app for its online banking service, a failure in the app means lost revenue through customer loss. If an airline uses an enterprise app for online ticket sales, a failure in the app means lost revenue through lost ticket sales.
The revenue generated-- directly or indirectly-- by the enterprise app will be far in excess of the costs associated with building it. Therefore, the reliability of the app once it's deployed is of paramount importance. If the app doesn't scale, or doesn't scale as well, the costs in lost revenue-- again, direct or indirect-- will be huge.
"So many much more interesting free software projects?" Like what? The window manager of the week? More KDE or Gnome silliness? Yet another incomplete and not-worth-my-time OpenOffice build? Mozilla, that isn't finished yet?
I have to say that United Linux is just as interesting as all the other unfinished hobby projects-- er, I mean "free software projects"-- out there.
Yes, the article does clearly state that TMC should be called to task... but then it fails to give any good reason for it. Every criticism of TMC's methodology is a debatable one. They point out, for example, that the LOC comparison is unfair, but then they speak only in vague terms about "excessive exception handling" to explain why.
Why don't you read the article, and then why don't you fuck off.
First of all, what mailing list is that, exactly? I'm not sure I believe that's an accurate representation of the facts. Phrases like "small army," "homeless encampment," and "international call for solidarity" make it pretty clear that that's a heavily biased report.
But most importantly, there's nothing evil about this, for several reasons.
1. Home Depot was ordered, by the Ontario Ministry of the Environment, to evict the squatters (not "homeless encampment," but squatters) in November, 2000. The order was based on the premise that the vacant lot was formerly the site of an iron foundry, and not fit for direct human habitation.
2. In December, 2000, Home Depot put flyers all over the squatters' tents saying that they would be clearing the site and asking people to leave. That pretty much blows your "with no notice" theory out of the water.
3. In August, Home Depot actually starting building shelters on the site in preparation for winter. Does that sound evil to you?
There's even more to the story. A good-- and unbiased-- synopsis can be found on the CBC's web site, here.
Did you read either of the articles? Nobody lied. At worst, some of the stuff TMC said is open for interpretation and debate. There's no clear evidence that anybody deliberately misrepresented the facts.
Hell, the TMC web site even says (paraphrasing here) that this doesn't mean J2EE is slower than.NET. It just means J2EE was slower than.NET in this case.
Are you trolling? Java server stuff isn't interpreted. Servlets and beans are compiled by the developer, while JSPs are compiled by the server (into servlets, incidentally) on demand. Some servers automatically compile all JSPs at start-up, while others wait for a request before compiling. Once all the JSPs have been compiled, Java server applications run as native, compiled Java bytecode.
Actually, in this case, it's pretty much about benchmarks and raw speed. Unlike a personal desktop computer or a desktop application, when you're programming an enterprise app your own productivity isn't what's important. The overall reliability and quality of the finished app is what's important. If you choose an enterprise framework that doesn't scale-- or that doesn't scale as well-- then you're in a bad spot. So it's important to know how these two frameworks compare so you can make an educated choice at the front end about which one is better to use. All other things being equal, the faster one is better.
Of course, in this situation all other things are most definitely not equal. If you want to deploy your enterprise app using a non-Microsoft OS, or if you want to avoid licensing fees for app servers, Java is pretty much your only choice. (Unless you go with a different type of framework altogether, like PHP or something like that. In some cases that's okay.)
(Given your user name and other info, I expected a troll. Turns out you said something reasonable. Weird.)
What you say is true on the desktop, but this comparison is between two server technologies. Desktops are fast enough these days for what we want to do with them, but servers are still often heavily overloaded. If you build a big n-tier web application, chances are it's for a commercial purpose, right? So your goal in life is to get more and more people to use that web application, so you can make more money and whatever whatever. If your application can't scale as far as you need it to, it's bad, bad. So performance is very important in situations where the size of the application user base needs to scale dependably.
I swear, the bigger a company gets, the more evil it gets.
You're making unsupportable generalizations here, you know that? Boeing, Home Depot, Fannie Mae, State Farm, Morgan Stanley, Target, P&G, Berkshire Hathaway, Safeway... these companies are all in the Fortune 50. Please list your complaints against each, in as much detail as possible, so we can all accept your assertion that big companies are automatically evil.
the sci-fi channel is running all the SG-1 episodes from the beginning. Consult your local listings, etc
Or you could just tune in on Monday nights from 7:00 to 11:00 Eastern time. Seeing as how Sci-Fi is a nationally programmed network, checking local listings is unnecessary.
Oh, I don't know. It had some pretty outstanding moments. Apart from the one that everybody already knows about, there was the scene where the captain was under cover trying to pass himself off as a harmless job-hunter to the local sheriff. His story isn't perfect, though, because he claims to have gotten a lead on a job in town from a Mr. So-n-so.
"When was the last time you talked to Mr. So-n-so?" asks the sheriff.
"Never did myself," says the captain. "Heard about him through (blah blah, some other connection)."
"Well, that's funny, because Mr. So-n-so died 'bout nine months back."
"Did he now?" asks the captain. Then there's like a five second pause, which is a long time on television. "So..." he says, real slowly, "would his job be available?"
Plus, you've gotta respect any series that writes in a cat named Schrodinger, and then doesn't explain the joke.
(Following their lead, I won't explain it either. If you don't know what Schrodinger's cat is, please turn in your Slashdot pass at the front desk and show yourself out.)
Honest mistake. Whether it's by coincidence or by design, Michael Shanks's voice is incredibly similar to James Spader's. They don't look very much alike, but close your eyes and it's a challenge to tell the two apart.
(Unrelated nitpick on the subject of voices and dialects. Jackson is a linguist, right? Why, oh why, does he mispronounce "Goa'uld" as "goold" just like O'Neill and the other humans? As a linguist, shouldn't he be able to pronounce it "go-ah-oold" just like Teal'c and the other non-Earthlink characters do? Grumble-mumble.)
The first problem with a Ringworld movie is the Ringworld itself. Any big-ticket Hollywood producer is going to want the Ringworld to look cool, right? After all, it's a big space ring, better make it look like a big space ring!
From space, the Ringworld would look like an astronomical object until you got close enough, at which point it would look like an infinite black wall, or like an infinite flat plain, depending on your orientation to it. From the surface, it would look just like a planet, only with an almost-invisible arch over it. It wouldn't even look cool from altitude above it; it's just too big. (There is a series of 3D renderings of the Ringworld available here. They're interesting, but they're definitely not gripping movie material.)
So any attempt to make a Ringworld movie is going to be crippled by the fact that they either have to make special effects that aren't that cool, or they have to make ones that aren't that accurate.
But-- as if that weren't enough-- the biggest problem is that the plot would pretty much have to be gutted. There's a ton of back-story in Ringworld: the Puppeteers, the Kzinti, the Man-Kzin wars, lucky Teela, invulnerable spaceship hulls, sunflowers, stasis fields, hyperdrive... it's a great book, but as a movie it would either be incomprehensible to most of the world, or include five minutes of exposition for every ten minutes of action. I mean, there's more intricate background in Ringworld than there is in The Lord of the Rings!LOTR got away with, "Once upon a time there was a bad man who made a magical ring." Ringworld would need to go into detail on-- or at least mention-- a dozen or more key ideas that are basically unrelated to each other. It would be a tough screenplay to write.
The alternative, of course, is to get rid of Niven's characters and back-story. Just get the main characters-- just humans, none of those pesky and expensive aliens-- to the Ringworld, have 'em crash, and have 'em find a way off. But that's not a particularly interesting story. It'd be difficult to make it interesting without going into some discussion of who built the Ringworld and why, and Niven's own explanation is unacceptable unless they make a Protector movie first and release it as a prequel.
I hate to say it, but I suppose I'd rather not see Ringworld on the big screen.
At least Lynch's Dune had style. Yeah, they diverged pretty heavily from the story of the novel. Yeah, Sting is a little embarrassing. But it's one of the best looking films of the 80's. And come on, José Ferrer is the Emperor, and Kenneth McMillan positively rocked as the Baron.
The Sci-Fi Channel miniseries just had no style, visually or otherwise. Given the choice, I'd rather watch Lynch's version.
Slashdot Mirror
I don't know the quote in question
"The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. Blessed is he who in the name of charity and good will shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who attempt to poison and destroy my brothers. And you will know my name is the Lord when I lay my vengeance upon thee."
Blam blam blam blam blam blam blam blam blam!
Christ, dude, there's no reason to get nasty. If you don't agree with me, fine, argue with me. Calling me names, though? That's just kinda childish, isn't it?
What you said in this post is basically unarguable. You said, essentially, that performance isn't the only important factor. Um... duh. But that's not what you originally said. You originally said that web servers are not expensive, which missed the point entirely. (If you can't solve your scalability problem by throwing more hardware at it, then the cost of the hardware is immaterial.) Then you said that trading performance for initial development time makes sense because you can buy more hardware for the money that you would have spent on software engineering. Which also misses the point, because you can find yourself in a situation where you saved money on development in the early stages, but you have to spend more money on development now to solve a scalability problem that can't be solved by buying more hardware. In that case, you save money on development at the beginning, but spend even more money on it later, which does not make sense for the bottom line.
So... how exactly am I ignoring "every fucking thing" you've said, and/or adding "all sorts of shit" that you didn't say?
Yes, some of his objections are certainly valid. If I ever implied that I think otherwise, then I misspoke. But saying "they lied!" as Neumann did is just going too far.
This is evil how? Sounds like good business to me. If you don't like it, compete with it.
What's that? You can't compete with it? Then maybe Home Depot is just better at what they do than you are. That's the nature of a free market; the strongest companies bubble up to the top.
No evil here. Move along.
Geez, dude, did you just use grep or something?
Read the article a second time, critically this time. When he says things like "THAT is clearly a lie," do you really think he's literally correct? Of course he isn't. He says they "lied," but what he really means is, "I disagree with this interpretation of the facts."
"Lie" has a very specific meaning: it means deliberately and knowingly saying something contrary to the truth. There's no evidence that anybody involved with this lied. There are different interpretations of the facts-- obviously-- but that's not the same as a lie.
I reiterate my point: don't jump to conclusions. And I add a second point: use your brain as you read.
Its not entirely clear to me from the articles that the performance gap is very large, or if it exists, or if it does, who is in the lead.
.NET is better; the point is that it matters which one is better, if in fact one of them is.
.NET are complex frameworks. It's entirely possible, though maybe not probable, that one or both of them will have at least one significant flaw that's not immediately obvious. Given that it's possible, I think it's worthwhile to do this kind of testing to see if it's true. The argument that performance doesn't matter isn't really a very good one, in my opinion.
.NET or J2EE would have nearly equal performance
.NET and J2EE are equivalent. They may be, they may not be. We don't know yet.
I agree completely, and I think I would have avoided some confusion if I'd made that more clear in the first place. The point is not that either J2EE or
Now, both J2EE and
I think that its safe to argue that for a given application, a proper implementation in
Unfortunately I'm not sure it's safe to say that. Until more side-by-side testing is done, it's not reasonable at all to say that
I feel confident saying that as long as the percieved performance gap is small, or at least manageable, performance will not drive decision making.
But, as I've pointed out elsewhere, enterprise applications are different from other kinds of applications. While desktop applications have basically unchanging user requirements, enterprise applications will be called on to handle ever-increasing user requirements. (Today we need to be able to handle 100 concurrent users of the system. In six months, we need to be able to handle 100,000 concurrent users. Can we do that without making any code changes to the application, or will we have to rewrite as we discover performance bottlenecks?) Because enterprise apps have to scale, the choice of tools and frameworks you use at the beginning is a much more important decision, if you want to avoid painting yourself into a corner.
Ohhhhkay. You're not following the reasoning here. You invest $X in your server hardware. In order to save money, you spend more on hardware so you can use a software framework that doesn't perform or scale as well but for which the developers can write the application faster. You deploy the application-- which had a fixed development cost of $Y-- on the server, which had a fixed capital cost of $X.
.NET framework is fundamentally flawed in some way, not knowing it and not acting on that information at the beginning of your project can cost you a fortune later on. How can we tell if J2EE or .NET or whatever else is flawed? Test it. Do side-by-side performance comparisons to tell us how the two frameworks compare in terms of reliability and scalability. There's really no other way to judge which of them is a better long-term investment.
.NET being a better choice. But that doesn't mean that benchmarks and comparisons are meaningless.
Six months later, your customers start going elsewhere because your web application is too slow. It's not scaling under load the way it needs to. That's okay, because you can just invest in more hardware, right?
Wrong. If the application or the application framework doesn't scale, then more hardware won't help. You have to go back to the developers again (at a cost of $Z, which as you point out is significantly more expensive than simply buying new hardware) so they can optimize or refactor or, in the worst case, just rewrite whole sections from scratch to improve scalability.
If-- and I'm not saying this is the case-- the J2EE framework or the
In other words, mosch, if you cut two weeks off of your project now, but have to invest two more months in it a year from now, your net cost is higher than if you took two extra weeks and used the better framework in the first place.
Of course, the whole point is kind of moot because in this case there's no conclusive evidence for either J2EE or
Well, the original poster asked for an example of evil, not an unbiased example of evil.
If it's only evil in the context of a biased report, then it's not exactly evil, is it?
Dude, do you understand that we're not talking about serving up static web pages here? We're talking about enterprise applications. These sorts of things are (1) extremely important to the companies that run them, and (2) very hard to cluster-ize. If your bank uses an enterprise app for its online banking service, a failure in the app means lost revenue through customer loss. If an airline uses an enterprise app for online ticket sales, a failure in the app means lost revenue through lost ticket sales.
The revenue generated-- directly or indirectly-- by the enterprise app will be far in excess of the costs associated with building it. Therefore, the reliability of the app once it's deployed is of paramount importance. If the app doesn't scale, or doesn't scale as well, the costs in lost revenue-- again, direct or indirect-- will be huge.
You're just not thinking, here.
"So many much more interesting free software projects?" Like what? The window manager of the week? More KDE or Gnome silliness? Yet another incomplete and not-worth-my-time OpenOffice build? Mozilla, that isn't finished yet?
I have to say that United Linux is just as interesting as all the other unfinished hobby projects-- er, I mean "free software projects"-- out there.
(Mod away.)
Yes, the article does clearly state that TMC should be called to task... but then it fails to give any good reason for it. Every criticism of TMC's methodology is a debatable one. They point out, for example, that the LOC comparison is unfair, but then they speak only in vague terms about "excessive exception handling" to explain why.
Why don't you read the article, and then why don't you fuck off.
First of all, what mailing list is that, exactly? I'm not sure I believe that's an accurate representation of the facts. Phrases like "small army," "homeless encampment," and "international call for solidarity" make it pretty clear that that's a heavily biased report.
But most importantly, there's nothing evil about this, for several reasons.
1. Home Depot was ordered, by the Ontario Ministry of the Environment, to evict the squatters (not "homeless encampment," but squatters) in November, 2000. The order was based on the premise that the vacant lot was formerly the site of an iron foundry, and not fit for direct human habitation.
2. In December, 2000, Home Depot put flyers all over the squatters' tents saying that they would be clearing the site and asking people to leave. That pretty much blows your "with no notice" theory out of the water.
3. In August, Home Depot actually starting building shelters on the site in preparation for winter. Does that sound evil to you?
There's even more to the story. A good-- and unbiased-- synopsis can be found on the CBC's web site, here.
Did you read either of the articles? Nobody lied. At worst, some of the stuff TMC said is open for interpretation and debate. There's no clear evidence that anybody deliberately misrepresented the facts.
.NET. It just means J2EE was slower than .NET in this case.
Hell, the TMC web site even says (paraphrasing here) that this doesn't mean J2EE is slower than
Don't jump to conclusions.
Are you trolling? Java server stuff isn't interpreted. Servlets and beans are compiled by the developer, while JSPs are compiled by the server (into servlets, incidentally) on demand. Some servers automatically compile all JSPs at start-up, while others wait for a request before compiling. Once all the JSPs have been compiled, Java server applications run as native, compiled Java bytecode.
Actually, in this case, it's pretty much about benchmarks and raw speed. Unlike a personal desktop computer or a desktop application, when you're programming an enterprise app your own productivity isn't what's important. The overall reliability and quality of the finished app is what's important. If you choose an enterprise framework that doesn't scale-- or that doesn't scale as well-- then you're in a bad spot. So it's important to know how these two frameworks compare so you can make an educated choice at the front end about which one is better to use. All other things being equal, the faster one is better.
Of course, in this situation all other things are most definitely not equal. If you want to deploy your enterprise app using a non-Microsoft OS, or if you want to avoid licensing fees for app servers, Java is pretty much your only choice. (Unless you go with a different type of framework altogether, like PHP or something like that. In some cases that's okay.)
(Given your user name and other info, I expected a troll. Turns out you said something reasonable. Weird.)
What you say is true on the desktop, but this comparison is between two server technologies. Desktops are fast enough these days for what we want to do with them, but servers are still often heavily overloaded. If you build a big n-tier web application, chances are it's for a commercial purpose, right? So your goal in life is to get more and more people to use that web application, so you can make more money and whatever whatever. If your application can't scale as far as you need it to, it's bad, bad. So performance is very important in situations where the size of the application user base needs to scale dependably.
Like shooting fish in a barrel...
I swear, the bigger a company gets, the more evil it gets.
You're making unsupportable generalizations here, you know that? Boeing, Home Depot, Fannie Mae, State Farm, Morgan Stanley, Target, P&G, Berkshire Hathaway, Safeway... these companies are all in the Fortune 50. Please list your complaints against each, in as much detail as possible, so we can all accept your assertion that big companies are automatically evil.
Pretty shortsighted, there. You would prefer maybe that we didn't have multinational corporations?
All in all, we're better off with the system as it is. Personally I'd rather not go back to the dark ages of the pre-war economy.
the sci-fi channel is running all the SG-1 episodes from the beginning. Consult your local listings, etc
Or you could just tune in on Monday nights from 7:00 to 11:00 Eastern time. Seeing as how Sci-Fi is a nationally programmed network, checking local listings is unnecessary.
This, my friends, is why god gave us TiVos.
E1 was by far the worst episode they've aired.
Oh, I don't know. It had some pretty outstanding moments. Apart from the one that everybody already knows about, there was the scene where the captain was under cover trying to pass himself off as a harmless job-hunter to the local sheriff. His story isn't perfect, though, because he claims to have gotten a lead on a job in town from a Mr. So-n-so.
"When was the last time you talked to Mr. So-n-so?" asks the sheriff.
"Never did myself," says the captain. "Heard about him through (blah blah, some other connection)."
"Well, that's funny, because Mr. So-n-so died 'bout nine months back."
"Did he now?" asks the captain. Then there's like a five second pause, which is a long time on television. "So..." he says, real slowly, "would his job be available?"
Cracked me up. What a great show.
Plus, you've gotta respect any series that writes in a cat named Schrodinger, and then doesn't explain the joke.
(Following their lead, I won't explain it either. If you don't know what Schrodinger's cat is, please turn in your Slashdot pass at the front desk and show yourself out.)
Honest mistake. Whether it's by coincidence or by design, Michael Shanks's voice is incredibly similar to James Spader's. They don't look very much alike, but close your eyes and it's a challenge to tell the two apart.
(Unrelated nitpick on the subject of voices and dialects. Jackson is a linguist, right? Why, oh why, does he mispronounce "Goa'uld" as "goold" just like O'Neill and the other humans? As a linguist, shouldn't he be able to pronounce it "go-ah-oold" just like Teal'c and the other non-Earthlink characters do? Grumble-mumble.)
The first problem with a Ringworld movie is the Ringworld itself. Any big-ticket Hollywood producer is going to want the Ringworld to look cool, right? After all, it's a big space ring, better make it look like a big space ring!
From space, the Ringworld would look like an astronomical object until you got close enough, at which point it would look like an infinite black wall, or like an infinite flat plain, depending on your orientation to it. From the surface, it would look just like a planet, only with an almost-invisible arch over it. It wouldn't even look cool from altitude above it; it's just too big. (There is a series of 3D renderings of the Ringworld available here. They're interesting, but they're definitely not gripping movie material.)
So any attempt to make a Ringworld movie is going to be crippled by the fact that they either have to make special effects that aren't that cool, or they have to make ones that aren't that accurate.
But-- as if that weren't enough-- the biggest problem is that the plot would pretty much have to be gutted. There's a ton of back-story in Ringworld: the Puppeteers, the Kzinti, the Man-Kzin wars, lucky Teela, invulnerable spaceship hulls, sunflowers, stasis fields, hyperdrive... it's a great book, but as a movie it would either be incomprehensible to most of the world, or include five minutes of exposition for every ten minutes of action. I mean, there's more intricate background in Ringworld than there is in The Lord of the Rings! LOTR got away with, "Once upon a time there was a bad man who made a magical ring." Ringworld would need to go into detail on-- or at least mention-- a dozen or more key ideas that are basically unrelated to each other. It would be a tough screenplay to write.
The alternative, of course, is to get rid of Niven's characters and back-story. Just get the main characters-- just humans, none of those pesky and expensive aliens-- to the Ringworld, have 'em crash, and have 'em find a way off. But that's not a particularly interesting story. It'd be difficult to make it interesting without going into some discussion of who built the Ringworld and why, and Niven's own explanation is unacceptable unless they make a Protector movie first and release it as a prequel.
I hate to say it, but I suppose I'd rather not see Ringworld on the big screen.
At least Lynch's Dune had style. Yeah, they diverged pretty heavily from the story of the novel. Yeah, Sting is a little embarrassing. But it's one of the best looking films of the 80's. And come on, José Ferrer is the Emperor, and Kenneth McMillan positively rocked as the Baron.
The Sci-Fi Channel miniseries just had no style, visually or otherwise. Given the choice, I'd rather watch Lynch's version.