You seem to be confused about security versus vulnerability. Vulnerabilities in legacy code do not equate to lack of a clue in security in new code. Nobody can make 10's of millions of lines of code secure overnight (or even within a few years), not even someone with Microsoft's resources.
We've seen significantly more secure NEW code coming from Microsoft. We've seen the shore up security in many area's. That's a HUGE thing.
Yes, there are going to be vulnerabilities, even for years to come. Such vulnerabilities happen in all products, including Linux and OSX.
Spotlight is not equivelent to WinFS. Spotlight is equivelent to Vista's "Fast Search", and while FastSearch can take advantage of WinFS, they are two different technologies (though linked to some extent).
That's Apple's marketing spin to make people think that WinFS is nothing more than fast indexed searching.
Indeed. I think there are some kick ass comercial unix debuggers available (or so i've heard, haven't really seen them), but Microsoft's debugger has always been bone simple to use, though not very featureful.
That's really changed with VS 2005, the debugger can be extended in many ways that leave your jaw laying on the ground. You can create custom "visualizers" to visual data structures in memory, and the popup "drilldown" features are a dream come true.
Want to be able to visual your HTML data buffer? XML? Custom document? Images? the visualizers are really cool.
C# is a compiled language, as is Java. You can't call something that's "JIT" compiled "interpreted". It isn't. It's compiled.
Actually, Java CAN be interpreted, it can also be compiled. Microsoft (particularly Anders Hejlsberg, C#'s principal author) claims that IL is designed strictly to be compiled, rather than interpreted, and this give it certain performance advanatages of a Java Byte Code. I don't know if that's true or not, but it does make a certain amount of sense.
One thing is for sure, the Java hotspot compiler is much more complex than the IL jitter, and that smacks of scalability problems. Also, from what I understand, the hotspot compiler will actually interpret code if no Jitted code is available yet, which means the byte code can't be generated assuming no interpretation.
Most of the trailers I saw were on SciFi, which is fine.. target market and all, but it was almost always DURING firefly, which is kind of preaching to the choir.
Sadly, it had a LOT of competition for screen time. It was only in theaters for a few weeks, which didn't give it much time for repeat viewers to build up sales. I remember wanting to go see it for a 4th time, and it wasn't playing anywhere, AND it wasn't in the cheap theaters yet either, that was weird.
Managed C++ isn't really C++, it's just CLI using C++ syntax (with other stuff as well).
You can still compile standard, binary C++ applications in VC++ 2005, with or without MFC. It's also very standard conforming (though it doesn't support C99 from what I know, but then again few people really seem to care).
Computers are much faster today than they were 10 years ago when they moved the graphics into the kernel. I don't think you'll find any performance problems with today's hardware.
What makes you think they're not cooperating in other areas?
In fact, Microsoft is working with the WaSP project to improve standards compliance. Just because there's a story about A doesn't mean B isn't happening.
There is a big difference between an agreement that says if any patents conflict with a format they won't be enforced and a patented format, licensed with restrictions.
No, there's not a big difference. The only difference is one of chance. If Sun discovers they have patents on technology covered by ODF, it's the same situation. The question becomes, do you want to gamble on whether sun will discover such patents or not.
You're confusing "open" and "open source."
No i'm not. The "open" in "open source" and "open standard" means the same thing, it's just whether or not it applies to a standard or source. Being GPL compatible doesn't determine whether something is open or not.
A document format cannot be (by definition) GPL compatible.
That's incorrect. The GPL explictly defines the conditions upon which patented work is compatible with the GPL. That condition is that the patent rights must be reciprocal to everyone that gets a copy of GPL'd source code that implements the format. In the case of Sun's patent covenent, they only require that Sun be granted reciprocal rights, not everyone who might use GPL'd implementations.
I find it interesting that you are so meticulous about interpreting Microsoft's license, yet you seem to ignore entirely Sun's license and patent covenent which contains very similar "loopholes". For instance, Sun's patent covenent promises not to sue anyone *SO LONG A SUN IS PARTICIPATING* in that version of OpenDocument.
So, for example, if Sun decided they didn't like the direction of OpenDocument 1.1, they could stop participating and then sue anyone for "suddenly discovered" patents.
Additionally, the "openness" of something has nothing to do with whether or not it's GPL compatible. There are many open source (and even Free, according the Free Software Foundation) licenses that are not GPL compatible. The Mozilla Public License, for instance.
I'm also skeptical that Sun's license is GPL compatible either, since they impose the additional requirement of granting Sun reciprocal patent rights (explictly Sun, not necessarily others), which violates the "no additional restrictions" clause of the GPL.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Oooooh, interpreted! Why didn't you say it was using such speed demon techniques?
How can you sit there with a straight face and tell me that Interpreted code startup isn't slow? You take interpreted code that runs at roughly 1/10th the speed of native code, THEN (because that's not fast enough) you fire off a CPU intensive compile in the background sucking up even more CPU cycles, and this IMPROVES performance HOW?
So, if the backround JIT is taking 50% of the CPU time, and the interpreted code is running at 1/10th native speed, that means that the code is running at 5% of what a native program would be running (assuming there aren't even any other programs running). No, of course, now I understand why startup times are blistering fast.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
I did explicitly say "single processor boxes". Hyperthreading MAY give you better performance, but many benchmarks are showing otherwise.
I've used a TON of java programs, and not *ONE* of them has ever given anywhere near the responsiveness of even a poorly written native application.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 2, Interesting
Also, background threads don't help with CPU intensive work on single processor boxes. It just steals more cycles from the CPU bound task. You seem to think that background threads magically create more cycles out of fairie dust.
Background thread or not, the GC and the JIT'er take CPU cycles, (and lots of them). The only time you get a benefit from background threads is when the foreground process is blocked waiting for something else. All too often you're left waiting all right (for the JIT'er to finish, or for the GC's time slice to end).
Just because something uses background threads doesn't mean it mysteriously improves performance.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 2, Interesting
A background thread doesn't help you the first time you access the application. It still has to JIT before the code can execute. Background threads can help with predicted access, but that's not always going to happen either. If the code runs faster than the JIT'er can JIT, you're still left waiting.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 2, Insightful
Yes, Java can equal C++ in terms of performance, if you ignore JIT startup lag, ignore the bloated memory footprint, and ignore the insanem performance losses when the garbage collector kicks in.
Other than that, in a bubble of pre-JIT'd code with only a single data point, Java Rules.
While Blu-Ray is clearly superior for data storage, the unwillingness of Sony to support Mandatory Managed Copy is very disturbing. Basically, without making Managed Copy mandatory, movie studios can decide whether or not you can exercise your fair use rights.
What about the apps that aren't included? Just because you include 2 or 3, then some of the dozen others can sue because you're not including THEM too.
TCP windowing is not the solution. It's a hack. If everyone started using high TCP Windows, retransmission would cripple the network. Of course you could counter that with fully error correcting protocols, but then you reduce bandwidth again as parity information increases. you also increase the load on the CPU and/or network processors.
It's like saying "I can hold my breath for 10 minutes under water if I meditation and chemicals to slow my heart rate", but that doesn't help someone who needs to move around and do things while underwater.
You need a solution that works for everything, without putting too much load on the infrastructure.
You're confused. Just because you can push 480Mb/s doesn't mean you're getting 480Mb/s throughput on any given connection. Suppose you had 1Gb/s on two connections seperated by 5000 miles. You really think you're going got get 1Gb/s? You think you're going to get 500Mb/s? 100Mb/s? The inherant latency delays in the protocol make it impossible to get anywhere near optimum bandwidth.
Sure, you can push 480Mb/s to 100 4.8Mb/s connections, but you're not going to push 480Mb/s to one. THAT is what they're talking about.
Slashdot Mirror
You seem to be confused about security versus vulnerability. Vulnerabilities in legacy code do not equate to lack of a clue in security in new code. Nobody can make 10's of millions of lines of code secure overnight (or even within a few years), not even someone with Microsoft's resources.
We've seen significantly more secure NEW code coming from Microsoft. We've seen the shore up security in many area's. That's a HUGE thing.
Yes, there are going to be vulnerabilities, even for years to come. Such vulnerabilities happen in all products, including Linux and OSX.
Spotlight is not equivelent to WinFS. Spotlight is equivelent to Vista's "Fast Search", and while FastSearch can take advantage of WinFS, they are two different technologies (though linked to some extent).
That's Apple's marketing spin to make people think that WinFS is nothing more than fast indexed searching.
Indeed. I think there are some kick ass comercial unix debuggers available (or so i've heard, haven't really seen them), but Microsoft's debugger has always been bone simple to use, though not very featureful.
v e/2005/11/24/2424.aspx
That's really changed with VS 2005, the debugger can be extended in many ways that leave your jaw laying on the ground. You can create custom "visualizers" to visual data structures in memory, and the popup "drilldown" features are a dream come true.
Want to be able to visual your HTML data buffer? XML? Custom document? Images? the visualizers are really cool.
For example, here's a regex visualizer:
http://regex.osherove.com/Articles/RegexKit.html
And here's an XML visualizer:
http://blogs.conchango.com/howardvanrooijen/archi
C# is a compiled language, as is Java. You can't call something that's "JIT" compiled "interpreted". It isn't. It's compiled.
Actually, Java CAN be interpreted, it can also be compiled. Microsoft (particularly Anders Hejlsberg, C#'s principal author) claims that IL is designed strictly to be compiled, rather than interpreted, and this give it certain performance advanatages of a Java Byte Code. I don't know if that's true or not, but it does make a certain amount of sense.
One thing is for sure, the Java hotspot compiler is much more complex than the IL jitter, and that smacks of scalability problems. Also, from what I understand, the hotspot compiler will actually interpret code if no Jitted code is available yet, which means the byte code can't be generated assuming no interpretation.
Um.. actually, no. Microsoft released an open source version of C# and the ISO standard CLI framework, called Rotor.
.NET framework, it does encompass everything you need to write code using C#.
While this doesn't encompass the entire
Most of the trailers I saw were on SciFi, which is fine.. target market and all, but it was almost always DURING firefly, which is kind of preaching to the choir.
Sadly, it had a LOT of competition for screen time. It was only in theaters for a few weeks, which didn't give it much time for repeat viewers to build up sales. I remember wanting to go see it for a 4th time, and it wasn't playing anywhere, AND it wasn't in the cheap theaters yet either, that was weird.
Managed C++ isn't really C++, it's just CLI using C++ syntax (with other stuff as well).
You can still compile standard, binary C++ applications in VC++ 2005, with or without MFC. It's also very standard conforming (though it doesn't support C99 from what I know, but then again few people really seem to care).
There are some graphics drivers in the kernel in Linux, such as the framebuffer driver, and I believe the nVidia driver.
The reason printer drivers were in the kernel was that they rely heavily upon the graphics subsystem, which was also in the kernel.
Computers are much faster today than they were 10 years ago when they moved the graphics into the kernel. I don't think you'll find any performance problems with today's hardware.
I don't see any window handle parameters there.
What makes you think they're not cooperating in other areas?
In fact, Microsoft is working with the WaSP project to improve standards compliance. Just because there's a story about A doesn't mean B isn't happening.
There is a big difference between an agreement that says if any patents conflict with a format they won't be enforced and a patented format, licensed with restrictions.
No, there's not a big difference. The only difference is one of chance. If Sun discovers they have patents on technology covered by ODF, it's the same situation. The question becomes, do you want to gamble on whether sun will discover such patents or not.
You're confusing "open" and "open source."
No i'm not. The "open" in "open source" and "open standard" means the same thing, it's just whether or not it applies to a standard or source. Being GPL compatible doesn't determine whether something is open or not.
A document format cannot be (by definition) GPL compatible.
That's incorrect. The GPL explictly defines the conditions upon which patented work is compatible with the GPL. That condition is that the patent rights must be reciprocal to everyone that gets a copy of GPL'd source code that implements the format. In the case of Sun's patent covenent, they only require that Sun be granted reciprocal rights, not everyone who might use GPL'd implementations.
I find it interesting that you are so meticulous about interpreting Microsoft's license, yet you seem to ignore entirely Sun's license and patent covenent which contains very similar "loopholes". For instance, Sun's patent covenent promises not to sue anyone *SO LONG A SUN IS PARTICIPATING* in that version of OpenDocument.
So, for example, if Sun decided they didn't like the direction of OpenDocument 1.1, they could stop participating and then sue anyone for "suddenly discovered" patents.
Additionally, the "openness" of something has nothing to do with whether or not it's GPL compatible. There are many open source (and even Free, according the Free Software Foundation) licenses that are not GPL compatible. The Mozilla Public License, for instance.
I'm also skeptical that Sun's license is GPL compatible either, since they impose the additional requirement of granting Sun reciprocal patent rights (explictly Sun, not necessarily others), which violates the "no additional restrictions" clause of the GPL.
Oooooh, interpreted! Why didn't you say it was using such speed demon techniques?
How can you sit there with a straight face and tell me that Interpreted code startup isn't slow? You take interpreted code that runs at roughly 1/10th the speed of native code, THEN (because that's not fast enough) you fire off a CPU intensive compile in the background sucking up even more CPU cycles, and this IMPROVES performance HOW?
So, if the backround JIT is taking 50% of the CPU time, and the interpreted code is running at 1/10th native speed, that means that the code is running at 5% of what a native program would be running (assuming there aren't even any other programs running). No, of course, now I understand why startup times are blistering fast.
I did explicitly say "single processor boxes". Hyperthreading MAY give you better performance, but many benchmarks are showing otherwise.
I've used a TON of java programs, and not *ONE* of them has ever given anywhere near the responsiveness of even a poorly written native application.
Also, background threads don't help with CPU intensive work on single processor boxes. It just steals more cycles from the CPU bound task. You seem to think that background threads magically create more cycles out of fairie dust.
Background thread or not, the GC and the JIT'er take CPU cycles, (and lots of them). The only time you get a benefit from background threads is when the foreground process is blocked waiting for something else. All too often you're left waiting all right (for the JIT'er to finish, or for the GC's time slice to end).
Just because something uses background threads doesn't mean it mysteriously improves performance.
A background thread doesn't help you the first time you access the application. It still has to JIT before the code can execute. Background threads can help with predicted access, but that's not always going to happen either. If the code runs faster than the JIT'er can JIT, you're still left waiting.
Yes, Java can equal C++ in terms of performance, if you ignore JIT startup lag, ignore the bloated memory footprint, and ignore the insanem performance losses when the garbage collector kicks in.
Other than that, in a bubble of pre-JIT'd code with only a single data point, Java Rules.
While Blu-Ray is clearly superior for data storage, the unwillingness of Sony to support Mandatory Managed Copy is very disturbing. Basically, without making Managed Copy mandatory, movie studios can decide whether or not you can exercise your fair use rights.
You know what the answer to that will be.
But yet you're mysteriously silent when Apple, Mozilla, and Opera CREATE AN ENTIRELY NEW NON-STANDARD TAG and add it to their browser (canvas).
What about the apps that aren't included? Just because you include 2 or 3, then some of the dozen others can sue because you're not including THEM too.
TCP windowing is not the solution. It's a hack. If everyone started using high TCP Windows, retransmission would cripple the network. Of course you could counter that with fully error correcting protocols, but then you reduce bandwidth again as parity information increases. you also increase the load on the CPU and/or network processors.
It's like saying "I can hold my breath for 10 minutes under water if I meditation and chemicals to slow my heart rate", but that doesn't help someone who needs to move around and do things while underwater.
You need a solution that works for everything, without putting too much load on the infrastructure.
That's assuming there are no transmission errors. If your connection is even slightly noisy, your rate is going to drop dramatically.
You're confused. Just because you can push 480Mb/s doesn't mean you're getting 480Mb/s throughput on any given connection. Suppose you had 1Gb/s on two connections seperated by 5000 miles. You really think you're going got get 1Gb/s? You think you're going to get 500Mb/s? 100Mb/s? The inherant latency delays in the protocol make it impossible to get anywhere near optimum bandwidth.
Sure, you can push 480Mb/s to 100 4.8Mb/s connections, but you're not going to push 480Mb/s to one. THAT is what they're talking about.