"The newer Javascript and SVG specs have support for sound/video and stuff like that too so Flash is probably going to be obsoleted within a few years if all the major browsers stay on top of things" No and they will not. For SVG to replace Flash you must have support for it built into every browser. IE doesn't want to do it because they are going to push silverlight. SVG will probably die on the vine because nobody can use it.
The problem I have here is I would think that this would come under reasonable cause. Someone calling the police and saying "Hey I found kiddie porn on this computer." seems to be reasonable cause to me.
Harder and more work are the same thing. With a straight interpreter a port should just be a recompile. With a JIT you must write the code generator. It is a trade off. And if you are on an X-86 it is a good trade off. But I will take a wild guess and this is how it will break down. X86 will get the best support. X86-64 will get second best. Every thing else will get much minimal support. Unless Sun pitches in for Sparc and IBM pitches in for PowerPC. XScale, Mips, Coldfire will all see little effort. That is just how I bet things will work out.
It is probably the right choice but like I said it is a trade off.
I have read those in the past. I was wondering if something had changed. If it is still a wash then the decrease in benchmark performance is a Linux issue and not an Ubuntu issue. Which to be honest what I would bet really is going on.
I was thinking the same thing. I can tell when a GSM cell phone is getting a call in about a 15 meter radius of my desk from the clicking over my PC's speakers.
Maybe but that will take a lot more testing to find out. The think is that an ideal scheduler would detect that the UI is mostly static and not take a lot of CPU time unless you where using the desktop. Of course nothing is ideal. I also doubt that there is one answer. 1. GCC compile times. Did they use the same version of GCC for all the tests? If not it could be extra optimization in the compiler taking up cycles. That is something I can live with. Did they use the same file system in all the tests? Just a lot of variables to sort through BUT Mono isn't a big problem in any of the tests I have listed.
Performance should never go down. Yes as you expect a PC to do more and more their will be more overhead but the over all performance should go up as the code gets optimized.
The problem here is we don't yet know why these benchmarks are running slower. Is it extra checks in the kernel for security? Is it fluff that isn't needed. Or is it bloat that needs to be optimized. So no people shouldn't just shut up. The cause needs to be found if possible fixed.
Why do you think this? I mean do you have a good reason or is it just because you don't like mono? Take a look at some of the tests. "Computational: The Dhrystone 2 performance within the BYTE Unix Benchmark was also the fastest on Ubuntu 7.04. There was approximately a 20% drop in performance between 7.04 and 7.10 that remained consistent even in the 8.04 and 8.10 releases. " This is NOT in mono. "Database: In our SQLite test of measuring the time to perform 2,500 SQL inserts, the performance hadn't dropped off after Ubuntu 7.04 but instead after 8.04 LTS. In this performance drop it was over 2.5x slower. " SQLlite isn't written in mono. "but in our compilation benchmarks we spotted major performance losses following the Feisty Fawn release. It was noticeably slower to compile Apache, PHP, and ImageMagick in the 7.10, 8.04, and 8.10 releases." GCC isn't written in mono. I could go on and on but many of the benchmarks have nothing to do with mono at all. Heck I am not a big fan of mono but your statment is baseless.
"Google don't have the Apple hype-machine/blogosphere/rumor sites going insane over unreleased products?"
Yea... Goggle doesn't have the Apple hype-machine/blogsphere/rumor sites....
Google has the Google hype-machine/blogsphere/rumor sites.... I think the problem has a lot more to do with T-Mobile than with the phone. T-Mobile is a very good carrier but they are not equal to AT&T or Verizon. Also the iPhone wasn't the first ipodish phone. AT&T made a deal with Apple and Motorola to produce an phone that worked with ITunes. That phone didn't set the world on fire but I think it got people interested in the iPhone.
Not really, as the salary goes up more people will brush up on their Cobol skills expanding the pool. In a company that is dependant on Cobol you will probably have some VB, C#, and or PHP/Perl/Python coders. The best of them will see that learning Cobol is worth the effort and move into a Cobol seat.
I am pretty sure that even the Norse came, looked around a bit, and went home. I know that the early Spanish explorers sure did. That is the difference between explorers and settlers.
I also left out one. 6. It can not prevent me from selling, giving away, or lending my copy. If I pay for a CD I can resell it. Same with a DVD, book, or video tape. So it needs to be the same with the digital copy.
Because it works? A good programmer is a good programmer. They all cost about the same. Really if you have a system that works why pay to reinvent the wheel? The pay to retest it.
Slashdot Mirror
"The newer Javascript and SVG specs have support for sound/video and stuff like that too so Flash is probably going to be obsoleted within a few years if all the major browsers stay on top of things"
No and they will not.
For SVG to replace Flash you must have support for it built into every browser. IE doesn't want to do it because they are going to push silverlight.
SVG will probably die on the vine because nobody can use it.
Not really.
We can at best hope that they don't toss out all of it because it was a legal search after all.
The problem I have here is I would think that this would come under reasonable cause.
Someone calling the police and saying "Hey I found kiddie porn on this computer." seems to be reasonable cause to me.
Too bad that nobody uses it.
Harder and more work are the same thing.
With a straight interpreter a port should just be a recompile. With a JIT you must write the code generator.
It is a trade off. And if you are on an X-86 it is a good trade off. But I will take a wild guess and this is how it will break down.
X86 will get the best support.
X86-64 will get second best.
Every thing else will get much minimal support.
Unless Sun pitches in for Sparc and IBM pitches in for PowerPC.
XScale, Mips, Coldfire will all see little effort.
That is just how I bet things will work out.
It is probably the right choice but like I said it is a trade off.
I have read those in the past. I was wondering if something had changed.
If it is still a wash then the decrease in benchmark performance is a Linux issue and not an Ubuntu issue.
Which to be honest what I would bet really is going on.
It uses a JIT compiler so it will be harder to port to another ISA.
Unless the JIT compiles to a virtual machine then it isn't so bad.
I just wonder how often the speed of javascript matters vs the network connection.
I tried to Chrome but never really noticed much difference.
I was thinking the same thing. I can tell when a GSM cell phone is getting a call in about a 15 meter radius of my desk from the clicking over my PC's speakers.
Or what Walt Disney dreamed EPCOT would be. Too bad after he died they turned EPCOT into a worlds fair that never ends.
Maybe but that will take a lot more testing to find out.
The think is that an ideal scheduler would detect that the UI is mostly static and not take a lot of CPU time unless you where using the desktop. Of course nothing is ideal.
I also doubt that there is one answer.
1. GCC compile times. Did they use the same version of GCC for all the tests? If not it could be extra optimization in the compiler taking up cycles. That is something I can live with.
Did they use the same file system in all the tests?
Just a lot of variables to sort through BUT Mono isn't a big problem in any of the tests I have listed.
Performance should never go down.
Yes as you expect a PC to do more and more their will be more overhead but the over all performance should go up as the code gets optimized.
The problem here is we don't yet know why these benchmarks are running slower.
Is it extra checks in the kernel for security?
Is it fluff that isn't needed.
Or is it bloat that needs to be optimized.
So no people shouldn't just shut up. The cause needs to be found if possible fixed.
I would like to see if this is an Ubuntu issue or Linux in general.
What about Fedora, OpenSuse, and Debian? How do they compare to Ubuntu?
Why do you think this? I mean do you have a good reason or is it just because you don't like mono?
Take a look at some of the tests.
"Computational: The Dhrystone 2 performance within the BYTE Unix Benchmark was also the fastest on Ubuntu 7.04. There was approximately a 20% drop in performance between 7.04 and 7.10 that remained consistent even in the 8.04 and 8.10 releases. "
This is NOT in mono.
"Database: In our SQLite test of measuring the time to perform 2,500 SQL inserts, the performance hadn't dropped off after Ubuntu 7.04 but instead after 8.04 LTS. In this performance drop it was over 2.5x slower. "
SQLlite isn't written in mono.
"but in our compilation benchmarks we spotted major performance losses following the Feisty Fawn release. It was noticeably slower to compile Apache, PHP, and ImageMagick in the 7.10, 8.04, and 8.10 releases."
GCC isn't written in mono.
I could go on and on but many of the benchmarks have nothing to do with mono at all.
Heck I am not a big fan of mono but your statment is baseless.
Problem solved, next.
"Google don't have the Apple hype-machine/blogosphere/rumor sites going insane over unreleased products?"
Yea... Goggle doesn't have the Apple hype-machine/blogsphere/rumor sites....
Google has the Google hype-machine/blogsphere/rumor sites....
I think the problem has a lot more to do with T-Mobile than with the phone.
T-Mobile is a very good carrier but they are not equal to AT&T or Verizon.
Also the iPhone wasn't the first ipodish phone. AT&T made a deal with Apple and Motorola to produce an phone that worked with ITunes. That phone didn't set the world on fire but I think it got people interested in the iPhone.
Not really, as the salary goes up more people will brush up on their Cobol skills expanding the pool. In a company that is dependant on Cobol you will probably have some VB, C#, and or PHP/Perl/Python coders.
The best of them will see that learning Cobol is worth the effort and move into a Cobol seat.
I am pretty sure that even the Norse came, looked around a bit, and went home.
I know that the early Spanish explorers sure did.
That is the difference between explorers and settlers.
I also left out one.
6. It can not prevent me from selling, giving away, or lending my copy. If I pay for a CD I can resell it. Same with a DVD, book, or video tape.
So it needs to be the same with the digital copy.
Because it works?
A good programmer is a good programmer. They all cost about the same.
Really if you have a system that works why pay to reinvent the wheel? The pay to retest it.
So the answer is. Because it works.
But then it fails as DRM.
The problem with DRM is this.
It only causes paying customers problems.
1. It can never deprive me of my media.
2. It can not restrict what devices I use my media on.
3. It can not restrict the storage format of the media.
In other words it is impossible.
Heck I do believe that copyright infringement is wrong. I just refuse to pay the price for others breaking the law.
Seems like a good time for some of the larger distros to help Samba out.
Then find a a discussion that has anything at all to do with it, this one doesn't.
Simple enough to fix. Just have it report the locations where you couldn't go the speed limit.
The idea would be to show where there are traffic jams.