Getting real-time depth information from the amount of IR reflected from a pulsed IR light is a pretty old technique. It's used in some input devices to detect where people are in front of the computer. The use of this information for video keying may be new, though.
Java's security model is used extensively in server-side Java. Say I'm working on the EJB loader which rely heavily on it.
Well, there are several issues there. First, EJB isn't the same as server-side Java. In fact, I suspect EJB represents only a tiny fraction of server-side Java. Second, the mere fact that EJB calls some security APIs doesn't mean that that actually accomplishes anything (class loaders are, of course, essential, but they are needed because of namespace issues, not for security). Third, C#/CLR does have similar functionality anyway.
(Incidentally, I am a Java developer myself, and have been since the first release in 1995.)
I didn't say it was "bad", I said "it isn't all that great yet". That primarily refers to the fact that performance in it is still lacking (relative to Java or C++). That's based on benchmarks that I did myself.
Also, C#'s APIs are nowhere near as mature and complete as Java's; exposing COM and Win32 just isn't enough.
I sympathize with Phil Greenspun greatly on this - though he's no longer actively involved in the company, it still feels awful to see your creation boom up and then pop.
Don't cry too hard. I'm sure the amount of money he made on the deal more than compensates for that.
I have used typewriters. Believe me--Emacs+TeX is a lot more productive (though Word may not be). My computer does boot a lot faster than my computer did 20 years ago, and it runs a lot faster, too (though Windows seems to be getting slower and slower). 1G machines allow me to do things I couldn't dream of doing a decade ago. I'm using lots of nifty data structures and algorithms that weren't known even a decade ago.
Mainstream software is perhaps getting worse, but if you know where to look, you can get software that works better, faster, and does more than anything previously available. Maybe Glynn is just buying the wrong software and hanging out with the wrong crowd. Or maybe he is just one of those glass-half-empty types.
"After several years debating minimum requirements for voting equipment, the computer science and public policy communities appear to agree that the Internet--as it exists today--can't sufficiently safeguard the privacy, security and reliability of the voting process.
In different words: it's just like the voting system we have now.
I don't see much use for "unmanaged applet code" (no more than for applet code that calls JNI on Java). But I see a lot of use for unsafe constructs and unmanaged code in C# applications, and that's where the unsafe features and C++ linkage in C# just look a lot nicer than JNI in Java. Hooking up a C-based regexp or image processing library to C# looks pretty simple, whereas with Java, it's a major effort.
As for memory addressing, I don't see a big issue there. Using unsafe constructs or unmanaged code, you can, of course, write machine dependent code, but you don't have to. And unlike C/C++ or JNI, such code is explicitly marked and clearly distinguishable from safe C# code.
What C# does is really not all that different from what Modula-3 and Ada have been doing with unsafe code. It's a pretty sensible, down-to-earth approach. As far as I can tell, there really isn't anything wrong with C#; it's a clone of Java with a few additional, useful features thrown in.
Of course, to be absolutely clear, I won't touch C# with the proverbial 10ft pole until some decent, open, non-Microsoft implementation comes out. Even if I wanted to use Windows, which I don't, Microsoft's current implementation is pretty iffy. And, despite Sun's FUD, Microsoft clearly still out-FUDs Sun.
At least on paper, Microsoft is supporting pretty much the same model with C#/CLR (but I wouldn't want to vouch for their implementation). And where in Java, you need permission to call JNI code, in C#, you need permission to call native or unsafe code.
"These animals live in the dark, in highly variable temperatures, where hot springs are surrounded by cold water. The warm water has no oxygen, so they have to have access to both cold and warm water," he explained
Wow, running hot and cold water. They need to work on lighting, though.
Heisenberg claims that because of his refusal to work on the bomb the Nazis did not obtain it. [...] but his dramatic reinvention of his role after the war. The Bohr papers again suggest that the failure of the German nuclear effort was due to Hitler being uninterested and their miscalculations rather than heroic resistance.
Heroic resistance apparently just wasn't required; as long as Heisenberg didn't push hard for a bomb project, it wasn't going to happen. I suspect that's about as much "refusal" as anyone could offer in Nazi Germany and live to talk about it.
I am very impresessed by Bohr's handling of the whole affair.
It was a lot easier for Bohr to reject the Nazis than for Heisenberg. To Bohr, they were foreign invaders. To Heisenberg, they were the government of his native country.
Ask yourself: at what point would you offer "heroic resistance" to your own government? When it starts interning minorities? When it starts displacing people based on their ethnic or racial origin? When you hear rumors of government-sponsored, deadly medical experiments? When it starts getting into wars with other countries? When it starts developing doomsday machines? When it starts poisoning the environment of other countries and enslaving others for economic gain? Does your responsibility end with not working on those projects yourself, or do you have a duty to find out more and sabotage those efforts? When do appeals to patriotism and defens turn into political manipulation and power tools?
These are very relevant questions today, and it is regrettable that people view the example of Nazi Germany as some distant historical aberration apparently of little relevance to their own lives.
I tried installing McAfee AV on a vanilla Windows system (Win98, I believe), right after installing Windows itself. The retail version came with a CD whose first action was to tell me that it was out of date and that I needed a 15Mbyte download. After waiting forever for that to complete, it crashed halfway through. When I tried to take advantage of their return policy, called them multiple times to get a return authorization and eventually sent everything back via registered mail with return receipt, I never heard back from them.
Oh, and as far as I'm concerned, the contract is invalid: McAfee never lived up to their side of the bargain. So, I don't feel bound by any gag clauses in it.
Well, as I was saying: for now, Java is still the better choice. But if good C#/CLR implementations become available on many platforms, Sun may well be in trouble. In fact, the most likely outcome is that you will see implementations that support both JVM and CLR and that allows developers to mix the two freely.
JNI was not intended to be used as a portable solution, but Unsafe is. I have to jump through serious hoops to get Applets out of the sandbox.
You can't get applets out of the sandbox, and neither can you use unsafe code from a C# sandbox. The point is that C#'s "unsafe" construct is very useful for non-applet applications and, as you point out yourself, Java has nothing equivalent. That's why "unsafe" is an advantage for C#: you get the same security model as with Java, but you get additional capabilities for desktop and server applications.
Not only do they expose the true costs of proprietary software, their annoying and intrusive tactics actually impose an additional cost on users of Microsoft products.
The BSA should conduct as many audits as possible. If you suspect that someone is using Microsoft products without the proper licenses, I encourage you to report them to the BSA. That's the best thing you can do for open source software. Companies that are 100% base on open source software have a very simple response to the BSA.
It's pretty clear that Heisenberg generally believed that his duties were to Germany. It's also pretty obvious that he didn't engage in a serious effort to build an A-bomb. That suggests that he didn't engage in some complex plot to sabotage a German A-bomb effort, he probably just didn't care enough to spend a lot of time on it.
That may seem like a mundane explanation, given what we now know about Nazi Germany and the power of nuclear bombs. But Heisenberg probably did not know the extent of Nazi atrocities and he also didn't know whether a real A-bomb would fizzle or bang.
It's tempting to see all of WWII in terms of villains and heroes. But most people were probably neither; they were just people trying to get on with their lives under difficult circumstances. Heisenberg could have been a hero or a villain, but he ended up being neither.
You implied that Lisp is a functional programming language, not me. I agree with you that you are wrong.
Imperative style rules the day. I believe that this reflects the way that human beings actually think.
Well, and I believe that you are wrong on this one, too. First, most knowledge people have is declarative and rule based, nor procedural. Second, from teaching students, it's clear that they have no problem with expressing themselves declaratively or functionally. Third, in my experience, the majority of non-trivial bugs in software systems are due to aliasing, unexpected state changes, and race conditions, so I would argue that people are very poor at imperative programming.
The use of "unsafe" in C# is roughly analogous to the use of JNI in Java: modules using unsafe features (or native code) are identifiable as such by the runtime, and applications with security needs can exclude them. As such, C# isn't any less safe than Java. In practice, the C# approach is likely to be safer and more secure than the Java approach, since using "unsafe" inside a C# program is much more localized and much easier to get right than writing a JNI module.
Furthermore, C# isn't even going after the same market as Java. Java's security model primarily comes into play for applets and mobile code, but that's only a tiny fraction of all applications. C#'s purpose in life is to allow programmers to create desktop and server applications more easily. For that purpose, an easy and robust interface to native code (regular expression libraries, XML parsers, etc.) is much more important than security.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft. But once there are C# implementations that are competitive with Java implementations and once C# has a life outside Microsoft, C# will be a serious threat to Java. And we may see a truly open source, efficient implementation of C# before we see one for Java.
For the time being, I still think Java is the more logical choice for open source applications. It may yet be a few years before competitive C# implementations and libraries come along. Sun still can keep their lead by innovating and extending the Java platform, cooperating with the open source community, and being honest about the strengths and limitations of the Java platform. But if Sun continues along their current course, they will lose sooner or later.
Well, I would think that anybody can figure out that "nice" expresses a personal preference.
But there is a real question: why do people use imperative programming languages so much? I think a big part is that, for old-style processors, they were a good match. That's why there were taught, and that's why our whole industry is built around them. And regardless of what the cause of their preference, the "hordes of VB programmers" simply aren't producing very good code, and a lot of that has to do with bugs due to imperative features.
The problems that people have with SML, Haskell, Prolog, and Lisp, are not due to their functional (=non-imperative) features but their syntax, their type systems, their support for higher-order functions, and their complexity. It is possible to design functional programming languages that are easy to use. Non-academics seem to have no trouble with the significant functional (=non-imperative) feature sets of Logo, Tcl, Splus, Fortran2000, XSL, SISAL, and PHP.
OCAML is comparable to other safe, compiled languages, including Java. SISAL and similar functional programming languages for numerical applications can even beat Fortran, mostly because there are more opportunities for optimization.
Functional programming language are an excellent match to the needs of modern processors. In fact, the only reason C and Fortran aren't complete dogs is because we invest enormous amounts of effort in adding special-purpose processor features to support imperative constructs, including speculative execution, branch prediction, byte-wise updates, instruction-level parallelism, etc. None of that hardware does any good for the computation itself--it just eats up precious real-estate in order to support the semantics of languages like C and Fortran. Functional programming languages not only remove the need for most of that hardware, they are also nicer to program in.
Of course, you can implement any language on JVM and CLR (even C with unsafe features). The question is: how efficient is it going to be?
A compiler for Itanium or P4 can directly take advantage of instruction-level parallelism and hyperthreading, while going through CLR or JVM precludes that. That's particularly important for functional programming languages because they make exploiting such parallelism much easier than object-oriented languages.
This isn't a case of a bad language winning because it was free (in fact, neither was free). Objective-C clearly was the better language for building GUIs and similar applications; C++ is not very good for those uses. But C++ is better than Objective-C for scientific applications, numerical algorithms, and embedded systems, and that's why it got widely adopted. The fact that industry then turned around and used C++ for GUI toolkits, well, don't blame the initial adopters of C++ for that. Note also that Simula is much closer to C++ than to Objective-C.
Overall, neither language really deserved to "win". There were better languages available then, and there are better languages available now.
You can compile both strict and lazy functional languages to CLR and JVM (there really isn't much of a difference between the two; even TRO can be dealt with reasonably well in the JVM). But don't expect miracles: the resulting code and performance will be usable but fairly mediocre.
Why? One major advantage of functional programming languages for optimization is that the compiler knows that almost nothing can change behind its back: variables can't get updated, data structures can't get changed, etc. With VLIW architectures like Itanium and hyperthreading, functional programming languages can potentially do much better relative to traditional languages than on older processors. But in order to so so, their compilers need a degree of control over code generation that simply isn't available if you go through CLR or JVM.
Furthermore, the entire runtime of a functional language is optimized for the kinds of allocation patterns that come along with functional programming, while CLR and JVM are optimized for OOP. For lazy functional languages, there are some additional issues when it comes to expressing lazy evaluation efficiently.
Altogether, though, I think it really doesn't matter. CLR and JVM are good and fairly flexible platforms, but platform evolution won't stop here. If anything, Sun is a bit more honest in this regard, making no bones about the fact that JVM is primarily a Java platform, even though there are dozens of other language frontends available for it; CLR claims universality, but really isn't any better than JVM.
If you don't care that much about performance, you can use your functional language under CLR and JVM. If you want a high-performance functional programming language, you can use one of the dedicated native code compilers and runtimes that will continue to be available. CLR and JVM will not end the evolution of other runtimes.
It's hard to tell what the motivation is for this license change. Is he perhaps talking about Lindows? Is Lindows using WINE and not giving back to the WINE project?
I think a change to an LGPL-like license should be done in such a way that commercial efforts like Lindows are still economically feasible (i.e., that they can add value in terms of packaging and add-ons), but that changes and bug fixes to the core WINE functionality are fed back into WINE. If that can be accomplished, then I think a change of WINE to LGPL is the right thing to do. If the WINE license becomes so restrictive as to make any commercial distributions of WINE-based systems uninteresting (because they exclude, for example, commercial add-ons from being bundled), then I think it would harm WINE.
He sees his bonuses greatly diminish if the German government adopts Linux.
Seriously, it really is an important issue if interaction with government entities requires the use of specific software available only from a single vendor, and that is what is increasingly happening. Microsoft can stay in the race by scrupulously opening up their file formats so that real interoperability with non-Microsoft applications is possible. But, so far, Office and other Microsoft applications still produce files whose format does not appear to be completely documented and that cannot be read and manipulated reliably by other applications.
Sorry, but you are confused about microkernels. Microkernels consist of separate servers that communicate with each other. Microkernels (like Mach) pay a speed penalty because they use more costly communications and protection mechanisms.
Using dynamically loadable modules doesn't make Linux a microkernel, and adding hooks wouldn't either. The performance penalty would be basically zero.
Slashdot Mirror
Getting real-time depth information from the amount of IR reflected from a pulsed IR light is a pretty old technique. It's used in some input devices to detect where people are in front of the computer. The use of this information for video keying may be new, though.
Well, there are several issues there. First, EJB isn't the same as server-side Java. In fact, I suspect EJB represents only a tiny fraction of server-side Java. Second, the mere fact that EJB calls some security APIs doesn't mean that that actually accomplishes anything (class loaders are, of course, essential, but they are needed because of namespace issues, not for security). Third, C#/CLR does have similar functionality anyway.
(Incidentally, I am a Java developer myself, and have been since the first release in 1995.)
I didn't say it was "bad", I said "it isn't all that great yet". That primarily refers to the fact that performance in it is still lacking (relative to Java or C++). That's based on benchmarks that I did myself.
Also, C#'s APIs are nowhere near as mature and complete as Java's; exposing COM and Win32 just isn't enough.
Don't cry too hard. I'm sure the amount of money he made on the deal more than compensates for that.
Mainstream software is perhaps getting worse, but if you know where to look, you can get software that works better, faster, and does more than anything previously available. Maybe Glynn is just buying the wrong software and hanging out with the wrong crowd. Or maybe he is just one of those glass-half-empty types.
In different words: it's just like the voting system we have now.
As for memory addressing, I don't see a big issue there. Using unsafe constructs or unmanaged code, you can, of course, write machine dependent code, but you don't have to. And unlike C/C++ or JNI, such code is explicitly marked and clearly distinguishable from safe C# code.
What C# does is really not all that different from what Modula-3 and Ada have been doing with unsafe code. It's a pretty sensible, down-to-earth approach. As far as I can tell, there really isn't anything wrong with C#; it's a clone of Java with a few additional, useful features thrown in.
Of course, to be absolutely clear, I won't touch C# with the proverbial 10ft pole until some decent, open, non-Microsoft implementation comes out. Even if I wanted to use Windows, which I don't, Microsoft's current implementation is pretty iffy. And, despite Sun's FUD, Microsoft clearly still out-FUDs Sun.
At least on paper, Microsoft is supporting pretty much the same model with C#/CLR (but I wouldn't want to vouch for their implementation). And where in Java, you need permission to call JNI code, in C#, you need permission to call native or unsafe code.
Wow, running hot and cold water. They need to work on lighting, though.
Heroic resistance apparently just wasn't required; as long as Heisenberg didn't push hard for a bomb project, it wasn't going to happen. I suspect that's about as much "refusal" as anyone could offer in Nazi Germany and live to talk about it.
I am very impresessed by Bohr's handling of the whole affair.
It was a lot easier for Bohr to reject the Nazis than for Heisenberg. To Bohr, they were foreign invaders. To Heisenberg, they were the government of his native country.
Ask yourself: at what point would you offer "heroic resistance" to your own government? When it starts interning minorities? When it starts displacing people based on their ethnic or racial origin? When you hear rumors of government-sponsored, deadly medical experiments? When it starts getting into wars with other countries? When it starts developing doomsday machines? When it starts poisoning the environment of other countries and enslaving others for economic gain? Does your responsibility end with not working on those projects yourself, or do you have a duty to find out more and sabotage those efforts? When do appeals to patriotism and defens turn into political manipulation and power tools?
These are very relevant questions today, and it is regrettable that people view the example of Nazi Germany as some distant historical aberration apparently of little relevance to their own lives.
I tried installing McAfee AV on a vanilla Windows system (Win98, I believe), right after installing Windows itself. The retail version came with a CD whose first action was to tell me that it was out of date and that I needed a 15Mbyte download. After waiting forever for that to complete, it crashed halfway through. When I tried to take advantage of their return policy, called them multiple times to get a return authorization and eventually sent everything back via registered mail with return receipt, I never heard back from them.
Oh, and as far as I'm concerned, the contract is invalid: McAfee never lived up to their side of the bargain. So, I don't feel bound by any gag clauses in it.
JNI was not intended to be used as a portable solution, but Unsafe is. I have to jump through serious hoops to get Applets out of the sandbox.
You can't get applets out of the sandbox, and neither can you use unsafe code from a C# sandbox. The point is that C#'s "unsafe" construct is very useful for non-applet applications and, as you point out yourself, Java has nothing equivalent. That's why "unsafe" is an advantage for C#: you get the same security model as with Java, but you get additional capabilities for desktop and server applications.
The BSA should conduct as many audits as possible. If you suspect that someone is using Microsoft products without the proper licenses, I encourage you to report them to the BSA. That's the best thing you can do for open source software. Companies that are 100% base on open source software have a very simple response to the BSA.
That may seem like a mundane explanation, given what we now know about Nazi Germany and the power of nuclear bombs. But Heisenberg probably did not know the extent of Nazi atrocities and he also didn't know whether a real A-bomb would fizzle or bang.
It's tempting to see all of WWII in terms of villains and heroes. But most people were probably neither; they were just people trying to get on with their lives under difficult circumstances. Heisenberg could have been a hero or a villain, but he ended up being neither.
I don't get your logic. If Heisenberg thought that German victory was assured anyway, why would he have needed Bohr's help or even an atomic bomb?
Imperative style rules the day. I believe that this reflects the way that human beings actually think.
Well, and I believe that you are wrong on this one, too. First, most knowledge people have is declarative and rule based, nor procedural. Second, from teaching students, it's clear that they have no problem with expressing themselves declaratively or functionally. Third, in my experience, the majority of non-trivial bugs in software systems are due to aliasing, unexpected state changes, and race conditions, so I would argue that people are very poor at imperative programming.
Furthermore, C# isn't even going after the same market as Java. Java's security model primarily comes into play for applets and mobile code, but that's only a tiny fraction of all applications. C#'s purpose in life is to allow programmers to create desktop and server applications more easily. For that purpose, an easy and robust interface to native code (regular expression libraries, XML parsers, etc.) is much more important than security.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft. But once there are C# implementations that are competitive with Java implementations and once C# has a life outside Microsoft, C# will be a serious threat to Java. And we may see a truly open source, efficient implementation of C# before we see one for Java.
For the time being, I still think Java is the more logical choice for open source applications. It may yet be a few years before competitive C# implementations and libraries come along. Sun still can keep their lead by innovating and extending the Java platform, cooperating with the open source community, and being honest about the strengths and limitations of the Java platform. But if Sun continues along their current course, they will lose sooner or later.
But there is a real question: why do people use imperative programming languages so much? I think a big part is that, for old-style processors, they were a good match. That's why there were taught, and that's why our whole industry is built around them. And regardless of what the cause of their preference, the "hordes of VB programmers" simply aren't producing very good code, and a lot of that has to do with bugs due to imperative features.
The problems that people have with SML, Haskell, Prolog, and Lisp, are not due to their functional (=non-imperative) features but their syntax, their type systems, their support for higher-order functions, and their complexity. It is possible to design functional programming languages that are easy to use. Non-academics seem to have no trouble with the significant functional (=non-imperative) feature sets of Logo, Tcl, Splus, Fortran2000, XSL, SISAL, and PHP.
Functional programming language are an excellent match to the needs of modern processors. In fact, the only reason C and Fortran aren't complete dogs is because we invest enormous amounts of effort in adding special-purpose processor features to support imperative constructs, including speculative execution, branch prediction, byte-wise updates, instruction-level parallelism, etc. None of that hardware does any good for the computation itself--it just eats up precious real-estate in order to support the semantics of languages like C and Fortran. Functional programming languages not only remove the need for most of that hardware, they are also nicer to program in.
A compiler for Itanium or P4 can directly take advantage of instruction-level parallelism and hyperthreading, while going through CLR or JVM precludes that. That's particularly important for functional programming languages because they make exploiting such parallelism much easier than object-oriented languages.
Overall, neither language really deserved to "win". There were better languages available then, and there are better languages available now.
Why? One major advantage of functional programming languages for optimization is that the compiler knows that almost nothing can change behind its back: variables can't get updated, data structures can't get changed, etc. With VLIW architectures like Itanium and hyperthreading, functional programming languages can potentially do much better relative to traditional languages than on older processors. But in order to so so, their compilers need a degree of control over code generation that simply isn't available if you go through CLR or JVM.
Furthermore, the entire runtime of a functional language is optimized for the kinds of allocation patterns that come along with functional programming, while CLR and JVM are optimized for OOP. For lazy functional languages, there are some additional issues when it comes to expressing lazy evaluation efficiently.
Altogether, though, I think it really doesn't matter. CLR and JVM are good and fairly flexible platforms, but platform evolution won't stop here. If anything, Sun is a bit more honest in this regard, making no bones about the fact that JVM is primarily a Java platform, even though there are dozens of other language frontends available for it; CLR claims universality, but really isn't any better than JVM.
If you don't care that much about performance, you can use your functional language under CLR and JVM. If you want a high-performance functional programming language, you can use one of the dedicated native code compilers and runtimes that will continue to be available. CLR and JVM will not end the evolution of other runtimes.
I think a change to an LGPL-like license should be done in such a way that commercial efforts like Lindows are still economically feasible (i.e., that they can add value in terms of packaging and add-ons), but that changes and bug fixes to the core WINE functionality are fed back into WINE. If that can be accomplished, then I think a change of WINE to LGPL is the right thing to do. If the WINE license becomes so restrictive as to make any commercial distributions of WINE-based systems uninteresting (because they exclude, for example, commercial add-ons from being bundled), then I think it would harm WINE.
Seriously, it really is an important issue if interaction with government entities requires the use of specific software available only from a single vendor, and that is what is increasingly happening. Microsoft can stay in the race by scrupulously opening up their file formats so that real interoperability with non-Microsoft applications is possible. But, so far, Office and other Microsoft applications still produce files whose format does not appear to be completely documented and that cannot be read and manipulated reliably by other applications.
Using dynamically loadable modules doesn't make Linux a microkernel, and adding hooks wouldn't either. The performance penalty would be basically zero.