First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers.
You are confusing "purity", "safety", and "security"; if you did what you suggest, you would indeed be writing drivers in "pure Java", but if those APIs were accessible, they would undermine safety.
If you ever want to distribute your project to places where such licenses are enforceable, you still face the same problem. So, unless you only want to distribute your code in Southern East West Africa, you better pay attention to those licenses.
To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib.
And the equivalent is true for C# "unsafe" code: there are restrictions on where it can be run from and what can run it.
So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.
The FUD is the nonsense Gosling was spewing about C#. Box is responding with hyperbole (he says so explicitly) to demonstrate how absurd Gosling's argument is.
Unfortunately, creating FUD seems to be a major occupation at Sun these days, and the targets are Sun's biggest competitors: Microsoft and Linux.
JVM - no, that's safe. JNI is an API, not a platform.
You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.
However, the C# solution is better than the Java solution: unsafe code in C# still contains substantially more error checking than equivalent C code linked through JNI, you generally need much less unsafe code in C# than in Java to accomplish the same task, and C# unsafe code doesn't need to be recompiled for different platforms and can just be distributed like other C# code.
Don's comments did not really add anything that wasn't covered in the Slashdot discussion.
What do you want? He is responding to an enormously stupid, self-serving comment from Gosling. You have to be clear and keep things simple in order to reach the kind of people who would swallow Gosling's nonsense in the first place.
IBM saw this years ago, and thus began the whole Cell architecture
This was completely obvious to everybody in the 1980's. What was surprising to most people was that Intel managed to succeed with the x86 architecture for so long without innovation.
AMD's (and now Intel's) approach of crambing more and more processing cores onto an IC might pay off in the short term, but like the "free lunch" of clock speed, will hit a roadblock when issues like memory bandwidth and caching schemes
And how do you think Cell addresses that? Right now, it's still just a lot of CPUs on a chip, with the same memory bottleneck as everybody else.
In fact, AMD and Intel probably are at a sweet spot with their processors where CPU power and memory bandwidth are fairly evenly matched for most applications. Cell, if anything, probably makes a bad tradeoff for real-world apps.
That's not much of a point. E.g., Atlas libraries support many different CPUs, and so do Fortran compilers. Many of those tools are already mature, widely used, conform to open standards, and are free for even for commercial use.
Sun has given some stuff to the open source community, but they have also kept some important stuff proprietary and even lied about it (most importantly, Java).
Fud fud and more goddamn fud more like it.
Funny, Sun fanboys like you scream "FUD" at the top of their lungs whenever anybody criticizes the company or has concerns about their future. But those concerns are well grounded. Sun has lost its traditional customer base, they are not a competitive Linux vendor, and they aren't going to make money off Java. How is the company going to survive?
Glibc is under the GPL with a linking exception, exactly to allow commercial development without paying anybody. The Linux kernel doesn't trigger the GPL. Qt is the only major system library that does not allow commercial development without paying someone.
Qt and KDE may be getting better, but a desktop platform must make it cheap and easy for developers to develop commercial software for it, and Qt doesn't do that. Its close ties with C++ further put it at a disadvantage.
The question isn't even whether it's "right" or "wrong" to pay Troll Tech, it's simply that vendors that try to put together commercial offerings out of Linux don't want to depend on a little company completely beyond their control.
I think Qt is essentially doomed in the long term because of these factors. Either the KDE guys will clone Qt, or the entire KDE project will just be replaced with Gnome. It doesn't matter whether KDE is better than Gnome or how much effort went into it.
You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows (or the Mac), no matter if you are developing in a traditional commercial sense or using any other financial model.
That's my point. In contrast, with Qt, I have to pay even for developing basic GUI apps. Therefore, if Qt became the default toolkit on Linux, it would put Linux at a big disadvantage relative to Windows and the Mac. Fortunately, Qt isn't the only toolkit on Linux.
Linux has really worked itself into a corner here.
No, Linux hasn't "worked itself into a corner" at all, because we do have Gtk+ and other toolkits that are covered by the LGPL. Those toolkits are friendly towards commercial use, and that's no accident. That's, after all, why most of the system libraries (C library, etc.) do allow closed source development.
There is a bizarre social aspect, a "we don't need your steenking commercial software" attitude that will probably keep it there, too. It's interesting to watch.
Linux needs commercial software much less than Windows or Macintosh because it comes with so much out of the box. And a lot of "steenking commercial software", we indeed don't need. A lot of "steenking commercial software" is also overpriced crap. But the small percentage of commercial apps that Linux needs and where commercial development makes sense, it support via toolkits like Gtk+.
Many of those source releases come with licenses that put you at legal risk if you as much as look at the code. Sun Java is an example of a serious offender there.
Generally, unless software comes with a known, proven free or open source license, do not look at the code. Otherwise, you may find yourself in legal hot water, and you may find yourself banned from many open source projects.
People concerned about "forking" neglect to take into account that forking doesn't mean less support for each fork. Once they get large enough, projects can fork in order to accomodate the needs of a new user community. That doesn't mean that people get left with a less supported option. Open source projects have the sizes and features that their user communities demand. If enough people want to keep using a piece of software that's 20 years old, then that piece of software is going to keep getting used.
And that's a lot more than one can say for commercial software: after all, does Microsoft still support Windows 3.1? Or Microsoft Word 1.0? Didn't think so. Lack of long-term support despite user demand is a serious problem for commercial software vendors because they need to bring out new versions in order to keep the revenue stream flowing.
Qt competes with both commercial and free toolkits, and it is expensive. For a fraction of the price of a commercial Qt license, I can get all of Visual Studio, not just a toolkit. It's also bad because platform vendors are reluctant to choose it for anything that might ever see commercial use because once they do, pricing for development on their platform is not under their control.
I don't know what a good way is to pay commercial companies like Troll Tech, I just know that the licensing model they actually have chosen severely limits Qt's acceptance. If they had used the LGPL, Gnome would never have gotten off the ground. The way it is, I'm sure KDE will eventually just go away.
SIMD support already exists, in the form of C, C++, and Fortran libraries (usually, as a small part of larger numerical libraries), as well as in language constructs in languages like Fortran.
Sun could "curry favors" with the FOSS community if they followed through on their committment made 10 years ago to turn Java over to a standards process. They would also curry favors if they just kicked out Schwartz, who has been behaving like a jerk towards FOSS.
Yet another database won't make any any difference in their reputation. If anything, it's just a sign that Sun doesn't play well withothers--they could just use PostgreSQL.
I think stuff like that shows you why closed source software can't be trusted. I bet bigger companies do similar sorts of things as well, as part of their "software updates" and all the other network traffic they generate.
It was filed in 1989, which is what counts. The fact that it floated around in the patent system until issue in 1998 shows how good the company is at playing the system.
Microsoft probably has a patent cross-licensing agreement with Matsushita, or at least they may have already forged an agreement (maybe as part of another deal). It actually stands to reason that Microsoft initiated all of this.
how can patent holders and companies owning "trade secret" IP be protected from information pirates?
Patents are not trade secrets. The fact that someone moved between companies doesn't make the patent claim any more valid.
Furthermore, the ossified Japanese economy needs to encourage mobility of workers, in particular, high-tech workers. The kind of exchange of knowledge and ideas that brings is essential to a high-tech economy. Even if your argument were valid that this has to do with employees moving between companies, it would still be a bad decision from that point of view.
What makes this patent particularly vile is that it was filed in 1989 but granted in 1998; this almost certainly constitutes a deliberate abuse of the patent system by Matsushita.
Most of the "ideas" that companies generate (in particular Japanese companies) were almost entirely developed in academia anyway; it is only companies that can afford to do carpet patenting in order to snare others in their so-called IP. Let's hope that universities will be fighting back aggressively by patenting themselves; once companies face huge patent portfolios without the ability to cross license, then maybe things will change.
I've always wondered why this was not championed as a default desktop environment for Linux.
Because people apparently didn't like hacking GUIs in Postscript and Objective C 20 years ago. And they sure as hell aren't going to like it now that they have things like Cairo, SVG, and C# available to them.
That, the unified display postscript, the great development environment, etc. seem to make it a natural and *sane* front end to the otherwise fragmented UI world of Linux.
The variety of desktops available for Linux is actually a great thing. Even if it weren't, you aren't going to fix it by adding another desktop into the mix, one with almost no users and no applications.
With the relative compatibility to the OS X/OPENSTEP libraries and code re-use, there could be a real network effect by making this a default environment for Linux and other Unixes.
How do you propose to "make it"? People choose the desktop they like, and that happens to be either Gnome or KDE.
If you seriously believe that NeXTStep and Mach are the way of the future, please do us all a favor and go buy a Macintosh (OS X doesn't really have a microkernel anymore, but who cares; it sounds good).
For the rest of us, fortunately, there are Gnome and KDE.
Gtk# is a binding of Gtk+ to C#; it uses whatever drawing mechanism the underlying Gtk+ implementation uses, which may well be different from Windows.Forms. However, with this announcement, it looks like everything is going to be using Cairo consistently, which is nice.
Whether it works is very much the point: enacting laws that we can't enforce is a pointless exercise in big government.
We don't need any laws restricting sales of video games to kids because it is the responsibility of parents to watch their kids. If parents don't want their kids to buy video games, then parents need to keep them from buying video games. If parents can't do that, they aren't doing their job, and that is nobody else's responsibility but theirs.
In any case, that's not the reason for going to vectorized graphics; vectorized graphics makes development and theming easier and allow new kinds of interaction. This isn't Apple's idea; Tcl/Tk and Gtk+, for example, use a stored vector canvas extensively. Apple is rather late to the party, sticking with bitmaps for a long time.
The time is about right to switch to vectorized graphics now: it is less efficient, it is harder to implement, but it will simplify application programming.
People on the OS X side rave about the smooth opaque window moves and exposes under Aqua and try to portray it as if it were some advanced technology in OS X. But you can get the same behavior under X11--turn on "backing store", it's a server option. Lots of other systems had the same functionality, including AmigaOS (notable because it came out around the same time as the original MacOS).
The reason it isn't turned on by default is that that kind of buffering consumes a lot of memory. Furthermore, once you turn it on by default, software authors will not pay attention to redraw logic anymore and applications will become unusable without backing store.
X11 made the decision to leave it off by default, OS X made the decision to turn it on.
Note that Gtk+ has been using vectorized themes and GUI elements already (i.e., elements could stored and scaled SVG); it simply rendered them client-side. This adds server-side support.
The situation with OS X appears to be reversed: it inherited vector drawing in the server, but mostly seemed to be using bitmaps for theming.
Slashdot Mirror
First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers.
You are confusing "purity", "safety", and "security"; if you did what you suggest, you would indeed be writing drivers in "pure Java", but if those APIs were accessible, they would undermine safety.
If you ever want to distribute your project to places where such licenses are enforceable, you still face the same problem. So, unless you only want to distribute your code in Southern East West Africa, you better pay attention to those licenses.
To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib.
And the equivalent is true for C# "unsafe" code: there are restrictions on where it can be run from and what can run it.
So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.
The FUD is the nonsense Gosling was spewing about C#. Box is responding with hyperbole (he says so explicitly) to demonstrate how absurd Gosling's argument is.
Unfortunately, creating FUD seems to be a major occupation at Sun these days, and the targets are Sun's biggest competitors: Microsoft and Linux.
JVM - no, that's safe. JNI is an API, not a platform.
You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.
However, the C# solution is better than the Java solution: unsafe code in C# still contains substantially more error checking than equivalent C code linked through JNI, you generally need much less unsafe code in C# than in Java to accomplish the same task, and C# unsafe code doesn't need to be recompiled for different platforms and can just be distributed like other C# code.
Don's comments did not really add anything that wasn't covered in the Slashdot discussion.
What do you want? He is responding to an enormously stupid, self-serving comment from Gosling. You have to be clear and keep things simple in order to reach the kind of people who would swallow Gosling's nonsense in the first place.
IBM saw this years ago, and thus began the whole Cell architecture
This was completely obvious to everybody in the 1980's. What was surprising to most people was that Intel managed to succeed with the x86 architecture for so long without innovation.
AMD's (and now Intel's) approach of crambing more and more processing cores onto an IC might pay off in the short term, but like the "free lunch" of clock speed, will hit a roadblock when issues like memory bandwidth and caching schemes
And how do you think Cell addresses that? Right now, it's still just a lot of CPUs on a chip, with the same memory bottleneck as everybody else.
In fact, AMD and Intel probably are at a sweet spot with their processors where CPU power and memory bandwidth are fairly evenly matched for most applications. Cell, if anything, probably makes a bad tradeoff for real-world apps.
That's not much of a point. E.g., Atlas libraries support many different CPUs, and so do Fortran compilers. Many of those tools are already mature, widely used, conform to open standards, and are free for even for commercial use.
Sun has given some stuff to the open source community, but they have also kept some important stuff proprietary and even lied about it (most importantly, Java).
Fud fud and more goddamn fud more like it.
Funny, Sun fanboys like you scream "FUD" at the top of their lungs whenever anybody criticizes the company or has concerns about their future. But those concerns are well grounded. Sun has lost its traditional customer base, they are not a competitive Linux vendor, and they aren't going to make money off Java. How is the company going to survive?
Glibc is under the GPL with a linking exception, exactly to allow commercial development without paying anybody. The Linux kernel doesn't trigger the GPL. Qt is the only major system library that does not allow commercial development without paying someone.
Qt and KDE may be getting better, but a desktop platform must make it cheap and easy for developers to develop commercial software for it, and Qt doesn't do that. Its close ties with C++ further put it at a disadvantage.
The question isn't even whether it's "right" or "wrong" to pay Troll Tech, it's simply that vendors that try to put together commercial offerings out of Linux don't want to depend on a little company completely beyond their control.
I think Qt is essentially doomed in the long term because of these factors. Either the KDE guys will clone Qt, or the entire KDE project will just be replaced with Gnome. It doesn't matter whether KDE is better than Gnome or how much effort went into it.
You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows (or the Mac), no matter if you are developing in a traditional commercial sense or using any other financial model.
That's my point. In contrast, with Qt, I have to pay even for developing basic GUI apps. Therefore, if Qt became the default toolkit on Linux, it would put Linux at a big disadvantage relative to Windows and the Mac. Fortunately, Qt isn't the only toolkit on Linux.
Linux has really worked itself into a corner here.
No, Linux hasn't "worked itself into a corner" at all, because we do have Gtk+ and other toolkits that are covered by the LGPL. Those toolkits are friendly towards commercial use, and that's no accident. That's, after all, why most of the system libraries (C library, etc.) do allow closed source development.
There is a bizarre social aspect, a "we don't need your steenking commercial software" attitude that will probably keep it there, too. It's interesting to watch.
Linux needs commercial software much less than Windows or Macintosh because it comes with so much out of the box. And a lot of "steenking commercial software", we indeed don't need. A lot of "steenking commercial software" is also overpriced crap. But the small percentage of commercial apps that Linux needs and where commercial development makes sense, it support via toolkits like Gtk+.
Many of those source releases come with licenses that put you at legal risk if you as much as look at the code. Sun Java is an example of a serious offender there.
Generally, unless software comes with a known, proven free or open source license, do not look at the code. Otherwise, you may find yourself in legal hot water, and you may find yourself banned from many open source projects.
People concerned about "forking" neglect to take into account that forking doesn't mean less support for each fork. Once they get large enough, projects can fork in order to accomodate the needs of a new user community. That doesn't mean that people get left with a less supported option. Open source projects have the sizes and features that their user communities demand. If enough people want to keep using a piece of software that's 20 years old, then that piece of software is going to keep getting used.
And that's a lot more than one can say for commercial software: after all, does Microsoft still support Windows 3.1? Or Microsoft Word 1.0? Didn't think so. Lack of long-term support despite user demand is a serious problem for commercial software vendors because they need to bring out new versions in order to keep the revenue stream flowing.
Qt competes with both commercial and free toolkits, and it is expensive. For a fraction of the price of a commercial Qt license, I can get all of Visual Studio, not just a toolkit. It's also bad because platform vendors are reluctant to choose it for anything that might ever see commercial use because once they do, pricing for development on their platform is not under their control.
I don't know what a good way is to pay commercial companies like Troll Tech, I just know that the licensing model they actually have chosen severely limits Qt's acceptance. If they had used the LGPL, Gnome would never have gotten off the ground. The way it is, I'm sure KDE will eventually just go away.
SIMD support already exists, in the form of C, C++, and Fortran libraries (usually, as a small part of larger numerical libraries), as well as in language constructs in languages like Fortran.
Sun could "curry favors" with the FOSS community if they followed through on their committment made 10 years ago to turn Java over to a standards process. They would also curry favors if they just kicked out Schwartz, who has been behaving like a jerk towards FOSS.
Yet another database won't make any any difference in their reputation. If anything, it's just a sign that Sun doesn't play well withothers--they could just use PostgreSQL.
I think stuff like that shows you why closed source software can't be trusted. I bet bigger companies do similar sorts of things as well, as part of their "software updates" and all the other network traffic they generate.
It was filed in 1989, which is what counts. The fact that it floated around in the patent system until issue in 1998 shows how good the company is at playing the system.
Microsoft probably has a patent cross-licensing agreement with Matsushita, or at least they may have already forged an agreement (maybe as part of another deal). It actually stands to reason that Microsoft initiated all of this.
how can patent holders and companies owning "trade secret" IP be protected from information pirates?
Patents are not trade secrets. The fact that someone moved between companies doesn't make the patent claim any more valid.
Furthermore, the ossified Japanese economy needs to encourage mobility of workers, in particular, high-tech workers. The kind of exchange of knowledge and ideas that brings is essential to a high-tech economy. Even if your argument were valid that this has to do with employees moving between companies, it would still be a bad decision from that point of view.
What makes this patent particularly vile is that it was filed in 1989 but granted in 1998; this almost certainly constitutes a deliberate abuse of the patent system by Matsushita.
Most of the "ideas" that companies generate (in particular Japanese companies) were almost entirely developed in academia anyway; it is only companies that can afford to do carpet patenting in order to snare others in their so-called IP. Let's hope that universities will be fighting back aggressively by patenting themselves; once companies face huge patent portfolios without the ability to cross license, then maybe things will change.
I've always wondered why this was not championed as a default desktop environment for Linux.
Because people apparently didn't like hacking GUIs in Postscript and Objective C 20 years ago. And they sure as hell aren't going to like it now that they have things like Cairo, SVG, and C# available to them.
That, the unified display postscript, the great development environment, etc. seem to make it a natural and *sane* front end to the otherwise fragmented UI world of Linux.
The variety of desktops available for Linux is actually a great thing. Even if it weren't, you aren't going to fix it by adding another desktop into the mix, one with almost no users and no applications.
With the relative compatibility to the OS X/OPENSTEP libraries and code re-use, there could be a real network effect by making this a default environment for Linux and other Unixes.
How do you propose to "make it"? People choose the desktop they like, and that happens to be either Gnome or KDE.
If you seriously believe that NeXTStep and Mach are the way of the future, please do us all a favor and go buy a Macintosh (OS X doesn't really have a microkernel anymore, but who cares; it sounds good).
For the rest of us, fortunately, there are Gnome and KDE.
Gtk# is a binding of Gtk+ to C#; it uses whatever drawing mechanism the underlying Gtk+ implementation uses, which may well be different from Windows.Forms. However, with this announcement, it looks like everything is going to be using Cairo consistently, which is nice.
Whether it works is very much the point: enacting laws that we can't enforce is a pointless exercise in big government.
We don't need any laws restricting sales of video games to kids because it is the responsibility of parents to watch their kids. If parents don't want their kids to buy video games, then parents need to keep them from buying video games. If parents can't do that, they aren't doing their job, and that is nobody else's responsibility but theirs.
Smaller file sizes mean faster loading.
In any case, that's not the reason for going to vectorized graphics; vectorized graphics makes development and theming easier and allow new kinds of interaction. This isn't Apple's idea; Tcl/Tk and Gtk+, for example, use a stored vector canvas extensively. Apple is rather late to the party, sticking with bitmaps for a long time.
The time is about right to switch to vectorized graphics now: it is less efficient, it is harder to implement, but it will simplify application programming.
People on the OS X side rave about the smooth opaque window moves and exposes under Aqua and try to portray it as if it were some advanced technology in OS X. But you can get the same behavior under X11--turn on "backing store", it's a server option. Lots of other systems had the same functionality, including AmigaOS (notable because it came out around the same time as the original MacOS).
The reason it isn't turned on by default is that that kind of buffering consumes a lot of memory. Furthermore, once you turn it on by default, software authors will not pay attention to redraw logic anymore and applications will become unusable without backing store.
X11 made the decision to leave it off by default, OS X made the decision to turn it on.
Note that Gtk+ has been using vectorized themes and GUI elements already (i.e., elements could stored and scaled SVG); it simply rendered them client-side. This adds server-side support.
The situation with OS X appears to be reversed: it inherited vector drawing in the server, but mostly seemed to be using bitmaps for theming.