Geek.com is running an opinion piece on the extensive reliance of programmers today on languages like Java and .NET. The author lambastes the performance penalties that are associated with running code inside virtualised environments, like Java's and .NET's. "It increases the compute burden on the CPU because in order to do something that should only require 1 million instructions (note that on modern CPUs 1 million instructions executes in about one two-thousandths (1/2000) of a second) now takes 200 million instructions. Literally. And while 200 million instructions can execute in about 1/10th of a second, it is still that much slower." The author poses an interesting challenge at the end of his piece - a challenge most OSNews readers will have already taken on. Note: Please note that many OSNews items now have a "read more" where the article in question is discussed in more detail.
To read all comments associated with this story, please click here.
Member since:2005-08-26
I installed Windows 2000 Pro on a P3 600E (coppermine) from the late 90's this past weekend.
The box had 384MB RAM, a TNT2, and 9GB drives on Ultra-Wide SCSI2.
I was seriously impressed with how fast, responsive, and darn smooth this box was. I had forgotten how smoothly win2k ran on machines like my old 400mhz K6-2.
So my question is what functional requirement can you do on Windows XP (or even vista) that you couldn't do in some way on Win2k? I'm not talking about eye-candy, funky interfaces, etc. I'm talking about what -kind- of application runs on Vista, but cannot, in any way, ever run on Win2000?
It's a function of time and engineering cost.
Photo management? Picasa.
Mp3 / Audio? iTunes 7.3.2 works on Windows 2000.
Games? This could be handled if they spent the time writing drivers / using technology other than directx. It's an engineering issue.
It seems to me that the core functions of the OS haven't expanded. It's what people expect the OS to do with the software pre-installed out of the box.
Photo management isn't an OS function.
Audio management isn't an OS function.
Could an OS provide hooks to handle such management? Absolutely, but that's not a core OS feature, and an OS that doesn't expose that by nature could have an application written for it that -does-.
I disagree. OS's today don't do a whole lot more than they did 10 years ago. In fact, most OS's today are just now catching up with what BeOS did 10 years ago.
Member since:
2008-03-19
"...but let's face it, they do a lot less too."
Duh. That was his point.