Certainly it would be up to a judge to set precedent on an issue like this.. my point was that a lawyer would be able to tell you whether such precedent had already been set in the past, or whether the applicable laws as written and as adjucated in the precedents would give a likelihood of being able to successfully contest the legality of this.
More power to those who wish to get sued over this to give this thing a test. I just feel it probably shouldn't be the Samba team, say. Not unless some lawyer does say 'we can take them!' and not unless some nice company is willing to pay the Samba team's legal bills.
I wouldn't be surprised if they used PDF rather than.DOC or.TXT so that someone couldn't just edit the file, remove the restriction declarations, and redistribute to innocents.
I bet you'd have a hard time finding a PDF file anywhere else on the Microsoft web site.
I completely agree with Ted here. Microsoft has obviously crafted this whole release as a booby trap/propaganda tool, nothing more. After all, of what use is this information, for any purpose other than attempts at implementation? Simply knowing what the data fields contain doesn't let you do any thing remotely resembling a proper security audit on their extension.
With this release, Microsoft is taking advantage of the fact that slashdot has no legal department to say 'hands off!'. All Microsoft has to do is to 'release' stuff like this and watch the fun as all of us open source fanboys get stirred up in reaction to it.
To me, the most offensive thing about Microsoft is their propensity for propaganda. Microsoft works very, *very* hard to portray reality in some very unintuitive ways, and this 'release' is more of the same doublethink. Ignorance is Strength, Slavery is Freedom, Microsoft is Open.
I don't get why everyone is advocating tricks to get around clicking 'ok' on the license agreement. Does anyone really think that a judge would uphold that dodge in court? 'Oh, you didn't know the license was there, so you accidentally used winzip rather than just double clicking on the executable'. I don't see this going over well.
The bigger issue here is that spreading stuff that Microsoft has indicated is not for distribution (and implementation) is no more morally respectable than someone ignoring inconvenient provisions in the Gnu General Public License. There may be a legal question as to whether anyone requires a license from Microsoft to implement any kind of spec, but taking the attitude that we have the right to take possession of their stuff is problematic at best.
We don't want people to get the idea that free software / open source software people are thieves, we want them to get the idea that we are better because we are willing to do hard work on our own.
Until a lawyer comes along and officially says that Microsoft's attempt at doing an orwellian double think specification release runs afoul of the law, leave this stuff alone.
In response to the question to Jeremy about work on making Samba authenticate against a network database, I'd like to put in a plug for Ganymede, the GPL'ed metadirectory we've been working on for the last four years.
With Ganymede, all network directory information is held in the Ganymede server's object database. When anyone creates a new user account or changes a password, or whatever, Ganymede writes out the appropriate data into the appropriate network directory services.
Here at ARL, when an admin creates a new user, that user's vital information gets set up in NIS, tacacs, Samba, and on a real live NT PDC via rsh and a Win32 Perl script.
Ganymede is extremely customizable and expandable, and includes password logic designed explicitly to support an NT PDC and Samba server as best as can be done, given the difference in password formats, and the difficulty in keeping things synced without keeping plaintext passwords around on disk.
We're working on preparing a 1.0pre1 release which will change a lot of things in the Ganymede system, including support for XML data import/export, but people interested can take a look right now at http://www.arlut.utexas.edu/gash2.
Just thought I'd offer a tidbit on X performance from the XFree86 FAQ. They recommend that you run the X server on Linux at nice priority -10 so the X server gets first priority for interactive use.
It would be interesting to see if doing this would make any impact on your feelings on X.
Do you have any evidence for these assertions? I can believe that BeOS's deeply multithreaded kernel and display logic is more efficient than X, and I believe that MacOS X's Quartz API provides some fancy operations that would be expensive to emulate in X, but you're really making a lot of sweeping statements here.
I happen to use X Windows over a network all the time, both at work on my X terminal to several machines in our computer center, and at home when I'm doing work there. If having X able to support those uses were a terribly heavy burden for the desktop, I could see moving away from it, but I don't believe that it is.
I'd love to be educated as to the precise technical factors that you believe make an X desktop so painfully slow, but I haven't heard any yet.
A) The whole X server over network paradigm isn't really needed for a local desktop (most of the time) by utilizing the framebuffer and hardware acceleration, this is provide an increadible peformance and memory usage boost. One reason I use BeOS that its GUI is so ridiculously responsive. Meanwhile KDE on a PII300 and TNT chugs along. Ever open up SysV init editor and resize the window? Talk 'bout major redraw. I really hope they put in support for writing directly to the framebuffer. That way OpenGL could be put on it and we'd be in desktop heaven.
I don't think XFree86 really has any significant overhead due to the X server network support, anymore. As others have pointed out whenever this topic comes up, local clients talk to the server through UNIX domain sockets (i.e., no TCP/IP involved), pipes, and shared memory. XFree86 is about as efficient as you can get while still having a separate process responsible for actually managing the display.
For embedded applications, it might make sense to have support for a system in which one process can serve as both application and as framebuffer driver, to reduce overhead, but in general this cost of the context switch is overwhelmingly outweighed by the convenience of having multiple applications able to put forth windows on the same screen, and by the convenience of not allowing everyone's code to have a chance at trashing registers on the video card, etc.
As far as DirectX-style API's, isn't DRI on XFree86 4.0 working quite well?
What I wish X had was an API for creating and switching between multiple video contexts, at different resolutions and color depths, the way Windows does. I'd love to be able to configure Wine to create an 8bit 640x400 video display context for playing StarCraft, rather than having to kill the X server, edit XFree86.conf and restart the whole thing in low-res/color mode.
There's plenty that's wrong with X and could use fixing, but the basic decision to use a separate server that can be communicated with over a network is not one of them.
Re:Are their not legal issues to OpenSSH/SSL???
on
FreeBSD 4.0 Released
·
· Score: 1
I believe it's the RSA public key algorithm that is coming out from patent this year, not DES. DES was made a US data processing standard for everyone to use, I don't believe it was ever patent encumbered in any restrictive way.
I installed the non-RPM version on my RedHat 6.0 box, and everything seems to work very well. The G2 beta would ping the CPU utilization on my 333mhz celeron box, but this RealPlayer7 beta is only taking up 1-2% of my CPU at most. Very nice.
Real has obviously been working on this one for a very long time (hence the mention of glibc 2.0 in the docs), and it seems like they've gotten it right. The player doesn't have nearly as many options in the preferences dialog as the Windows version, and I've noticed a GUI glitch (the percent complete bar seems to go to infinity when playing a live stream source) already, but it is so much better than the old G2 beta.
And for those who are concerned about Real's privacy protections, take a look at the latest Windows RealPlayer.. they have a many-tabbed dialog which discusses *everything* that could be in the slightest way privacy related, with full explanations and an opt-out for everything. It looks like the Linux version isn't quite as refined, but Real seems to be putting their heart in the right place on this one. I actually had a short email conversation with a person at Real who was involved with their privacy policy for Real7, and they really do seem to have gotten religion on this one.
Wow, where has Bruce come out against all of these things? He certainly seemed comfortable with them in Islands In The Net, which portrayed massive bioengineered food production.
All of your arguments are very well-taken, though, and make good sense. People who let warm fuzzies displace engineering judgement as to the best course of action are begging for unfortunate and unintended consequences.
Bruce Sterling is the best 'post-cyberpunk' author I've ever read, and he consistently lays out interesting scenarios for what a extremely high tech culture might be like.
His environmental rants are not at all off base.. capitalism != environmental havoc? No more than communism, certainly (have you seen the state of play in the former Warsaw Pact countries? Bruce has..), but billions upon billions of consumers eat a lot of raw land and resources, and the extinction rate since humans became civilized has been higher than at any time since the dinosaurs died. That's a bit of environmental havoc for you, right there.
The notion that government subsidizing is at the root of all harm from capitalism is misguided.. the market, as currently structured, is not capable of accurately accounting all the costs of consumerism. Capitalism is efficient at what it does, and it's the best thing going by all means, but it's only the best thing, not the perfect thing.
This has been gone over many times here and elsewhere, and the point that trying to redo all configuration files as XML would be of very limited benefit is well taken. I do like what Apple has apparently done in terms of using XML to represent consistent meta-information for their configuration files. That makes a lot more sense to me than the SYSV-style run-level directory structure, and I hope that some brave Linux distribution grabs on to the idea.
What warez trading on slashdot? What software pirates? What too lazy to buy software? Yeah, I guess the four+ years I've spent working on my GPL'ed project is just, sheer, rank laziness.
Puhleeze. There's a good argument to be made that lots of slashdot readers have a 'free software or die' mentality, but I've seen no one with any stature or credibility in the community assert that software that isn't free should be stolen. Yawn.
I am interested in your hit-and-run assertion that slashdot readers are violating a Biblical code of ethics, though.
A whole lot of good points in joss' post. I was very happy to see joss recommend my own indentation style, which I am very religious about.
I also especially liked joss' comments on the heavy cost of Java's immutable String class. It is disgustingly expensive to do a lot of string-type operations in Java because you have to create a new String object every time you work with a frequently changing string. They tried to make StringBuffer work efficiently with the String class.. if you extract a String from a StringBuffer, it actually re-uses the char[] array from the StringBuffer, so the overhead there is lower than you might think, but if you then try to re-use that same StringBuffer (by setting the StringBuffer size to zero and then adding new chars into it), StringBuffer behaves very poorly. It actually copies the char buffer from the old String at its full size before zero'ing it out, so if you ever extract a large String from a StringBuffer, you can get some very bad memory usage if you try to continue working with that StringBuffer thereafter.
I really love Java, and I've been working with it almost exclusively for the last four years, but there are many things like this that are only slowly being fixed. The right way to think about Java is as an operating system, with all of the complexity that that implies. You wouldn't expect a four year old operating system with all of the features that Java supports these days to be terribly mature, and Java still has a way to go.
For all of that, I do love Java, because it does work surprisingly well, all in all. My project (see my.sig) couldn't have been done with the resources we had to devote to it using anything else, and Java's precision, exception support, threading, API collection, and garbage collection make it possible to do very ambitious things with it.
Swing is getting better in 1.3, but too much of Swing is still under-specified. One problem with Swing is that all of the Swing objects are internally divided into a model and a view/controller, and a listener scheme is used to allow the view/controller to communicate with the model, and vice-versa.
One problem with that is that when you register your own code as a listener to the activity reported by the Swing component, you are just another listener as far as the view/controller is concerned. There's no way to specify that your code's listener should be called before the internal model's listener, so you can't have your code attempt to verify a proposed GUI action and reject it if it isn't viable. At least, you can't do this reliably across different kinds of Swing components, because the level of detail on the components' behavior is not specified well enough. You can go and look at the source code for the component, but since the behavior you may be depending on isn't part of the spec for the component, you can't really rely on it.
Not sure if that made sense, but basically Swing suffers a bit from the high level of complexity Sun put into it, and even with 1.3 it is still in need of more maturity. It is getting there, but Sun made their job a lot harder than it had to be by getting fancy with their pluggable look-and-feel support.
No, the whole OS wouldn't be magically made open source. If they were called on it, they would have the option of removing/rewriting that code to get out of violation of the license. There is nothing in the GPL that forces anyone to accept it, or use any code licensed under it.
All that the license does is state the terms under which code covered under the GPL can be used and distributed.
ESR talks about the free rider problem in The Cathedral And The Bazaar. The whole free software movement is predicated on people being able to take more than they give back, on the assumption that enough people will give back to make it all worthwhile.
Which it is, of course, or so many wouldn't do it. Somebody ripping off GPL software in way the this anonymous coward describes is damaging not because of the free ride gotten (we *want* you to have *free* code), but because it threatens to undermine the enforceability of the GPL. I agree with the other poster.. if anyone ever catches you at your theft and can prove it on any significant scale, you and/or your corporation certainly deserve to be prosecuted.
Yup, exactly. On many platforms you get decent time slicing behavior, but the precise scheduling algorithms were left unspecified in the standard to allow compliant implementations of Java on platforms with varying thread support.
You can't depend on threads in a Java program executing in any sort of order, unless you use the synchronized keyword and the java.lang.Object.wait() and java.lang.Thread.join() methods to expressly indicate your inter-thread relationships.
On many JVM's you will get reasonable behavior if you throw a bunch of threads up in the air with the same priority level and the expectation that they'll all get a reasonable amount of time relative to each other, but that's not guaranteed in the spec.
There are many good books on Java threading, including especially Doug Lea's Concurrent Programming Java, which talks not only about Java threading, but also about all of the issues that you have to face when designing for a multithreading/multiprocessing environment. That includes deadlocks, thread starvation, resource allocation, locks, semaphores, and a whole lot more. Highly recommended.
Preemption is allowed, yes, and there are guaranteed atomic operations (reference and integer assignment, at the very least). That's why I backpedalled and said that the JLS did indeed have guarantees on thread semantics.
It just doesn't have any guarantee as to when a particular thread will be run, nor whether a thread will ever be switched unless the active thread comes to the end of its execution or to a wait() call. In practice, every JVM that I care about will do those things, and I don't bother seeking out a Palm Pilot or Win 3.1 JVM to test my code on, but in theory it's something to be aware of.
Slashdot Mirror
Certainly it would be up to a judge to set precedent on an issue like this.. my point was that a lawyer would be able to tell you whether such precedent had already been set in the past, or whether the applicable laws as written and as adjucated in the precedents would give a likelihood of being able to successfully contest the legality of this.
More power to those who wish to get sued over this to give this thing a test. I just feel it probably shouldn't be the Samba team, say. Not unless some lawyer does say 'we can take them!' and not unless some nice company is willing to pay the Samba team's legal bills.
I wouldn't be surprised if they used PDF rather than .DOC or .TXT so that someone couldn't just edit the file, remove the restriction declarations, and redistribute to innocents.
I bet you'd have a hard time finding a PDF file anywhere else on the Microsoft web site.
I completely agree with Ted here. Microsoft has obviously crafted this whole release as a booby trap/propaganda tool, nothing more. After all, of what use is this information, for any purpose other than attempts at implementation? Simply knowing what the data fields contain doesn't let you do any thing remotely resembling a proper security audit on their extension.
With this release, Microsoft is taking advantage of the fact that slashdot has no legal department to say 'hands off!'. All Microsoft has to do is to 'release' stuff like this and watch the fun as all of us open source fanboys get stirred up in reaction to it.
To me, the most offensive thing about Microsoft is their propensity for propaganda. Microsoft works very, *very* hard to portray reality in some very unintuitive ways, and this 'release' is more of the same doublethink. Ignorance is Strength, Slavery is Freedom, Microsoft is Open.
I don't get why everyone is advocating tricks to get around clicking 'ok' on the license agreement. Does anyone really think that a judge would uphold that dodge in court? 'Oh, you didn't know the license was there, so you accidentally used winzip rather than just double clicking on the executable'. I don't see this going over well.
The bigger issue here is that spreading stuff that Microsoft has indicated is not for distribution (and implementation) is no more morally respectable than someone ignoring inconvenient provisions in the Gnu General Public License. There may be a legal question as to whether anyone requires a license from Microsoft to implement any kind of spec, but taking the attitude that we have the right to take possession of their stuff is problematic at best.
We don't want people to get the idea that free software / open source software people are thieves, we want them to get the idea that we are better because we are willing to do hard work on our own.
Until a lawyer comes along and officially says that Microsoft's attempt at doing an orwellian double think specification release runs afoul of the law, leave this stuff alone.
In response to the question to Jeremy about work on making Samba authenticate against a network database, I'd like to put in a plug for Ganymede, the GPL'ed metadirectory we've been working on for the last four years.
With Ganymede, all network directory information is held in the Ganymede server's object database. When anyone creates a new user account or changes a password, or whatever, Ganymede writes out the appropriate data into the appropriate network directory services.
Here at ARL, when an admin creates a new user, that user's vital information gets set up in NIS, tacacs, Samba, and on a real live NT PDC via rsh and a Win32 Perl script.
Ganymede is extremely customizable and expandable, and includes password logic designed explicitly to support an NT PDC and Samba server as best as can be done, given the difference in password formats, and the difficulty in keeping things synced without keeping plaintext passwords around on disk.
We're working on preparing a 1.0pre1 release which will change a lot of things in the Ganymede system, including support for XML data import/export, but people interested can take a look right now at http://www.arlut.utexas.edu/gash2.
Berlin Home Page
Jim Gettys is a name that should be familiar to all old-time X developers, as his name is on a whole lot of the code from way back when
Anyone with some free moderation points might want to bump up his post.
Just thought I'd offer a tidbit on X performance from the XFree86 FAQ. They recommend that you run the X server on Linux at nice priority -10 so the X server gets first priority for interactive use.
It would be interesting to see if doing this would make any impact on your feelings on X.
Do you have any evidence for these assertions? I can believe that BeOS's deeply multithreaded kernel and display logic is more efficient than X, and I believe that MacOS X's Quartz API provides some fancy operations that would be expensive to emulate in X, but you're really making a lot of sweeping statements here.
I happen to use X Windows over a network all the time, both at work on my X terminal to several machines in our computer center, and at home when I'm doing work there. If having X able to support those uses were a terribly heavy burden for the desktop, I could see moving away from it, but I don't believe that it is.
I'd love to be educated as to the precise technical factors that you believe make an X desktop so painfully slow, but I haven't heard any yet.
A) The whole X server over network paradigm isn't really needed for a local desktop (most of the time) by utilizing the framebuffer and hardware acceleration, this is provide an increadible peformance and memory usage boost. One reason I use BeOS that its GUI is so ridiculously responsive. Meanwhile KDE on a PII300 and TNT chugs along. Ever open up SysV init editor and resize the window? Talk 'bout major redraw. I really hope they put in support for writing directly to the framebuffer. That way OpenGL could be put on it and we'd be in desktop heaven.
I don't think XFree86 really has any significant overhead due to the X server network support, anymore. As others have pointed out whenever this topic comes up, local clients talk to the server through UNIX domain sockets (i.e., no TCP/IP involved), pipes, and shared memory. XFree86 is about as efficient as you can get while still having a separate process responsible for actually managing the display.
For embedded applications, it might make sense to have support for a system in which one process can serve as both application and as framebuffer driver, to reduce overhead, but in general this cost of the context switch is overwhelmingly outweighed by the convenience of having multiple applications able to put forth windows on the same screen, and by the convenience of not allowing everyone's code to have a chance at trashing registers on the video card, etc.
As far as DirectX-style API's, isn't DRI on XFree86 4.0 working quite well?
What I wish X had was an API for creating and switching between multiple video contexts, at different resolutions and color depths, the way Windows does. I'd love to be able to configure Wine to create an 8bit 640x400 video display context for playing StarCraft, rather than having to kill the X server, edit XFree86.conf and restart the whole thing in low-res/color mode.
There's plenty that's wrong with X and could use fixing, but the basic decision to use a separate server that can be communicated with over a network is not one of them.
I believe it's the RSA public key algorithm that is coming out from patent this year, not DES. DES was made a US data processing standard for everyone to use, I don't believe it was ever patent encumbered in any restrictive way.
I installed the non-RPM version on my RedHat 6.0 box, and everything seems to work very well. The G2 beta would ping the CPU utilization on my 333mhz celeron box, but this RealPlayer7 beta is only taking up 1-2% of my CPU at most. Very nice.
Real has obviously been working on this one for a very long time (hence the mention of glibc 2.0 in the docs), and it seems like they've gotten it right. The player doesn't have nearly as many options in the preferences dialog as the Windows version, and I've noticed a GUI glitch (the percent complete bar seems to go to infinity when playing a live stream source) already, but it is so much better than the old G2 beta.
And for those who are concerned about Real's privacy protections, take a look at the latest Windows RealPlayer.. they have a many-tabbed dialog which discusses *everything* that could be in the slightest way privacy related, with full explanations and an opt-out for everything. It looks like the Linux version isn't quite as refined, but Real seems to be putting their heart in the right place on this one. I actually had a short email conversation with a person at Real who was involved with their privacy policy for Real7, and they really do seem to have gotten religion on this one.
Yeah, it was the weirdest thing I had ever seen. Very much influenced by BattleStar Galactica, as I recall.. they were out at about the same time.
The internet is great, the internet is good, the internet has a Salvage 1 Fan Page.
Wow, where has Bruce come out against all of these things? He certainly seemed comfortable with them in Islands In The Net, which portrayed massive bioengineered food production.
All of your arguments are very well-taken, though, and make good sense. People who let warm fuzzies displace engineering judgement as to the best course of action are begging for unfortunate and unintended consequences.
Bruce Sterling is the best 'post-cyberpunk' author I've ever read, and he consistently lays out interesting scenarios for what a extremely high tech culture might be like.
His environmental rants are not at all off base.. capitalism != environmental havoc? No more than communism, certainly (have you seen the state of play in the former Warsaw Pact countries? Bruce has..), but billions upon billions of consumers eat a lot of raw land and resources, and the extinction rate since humans became civilized has been higher than at any time since the dinosaurs died. That's a bit of environmental havoc for you, right there.
The notion that government subsidizing is at the root of all harm from capitalism is misguided.. the market, as currently structured, is not capable of accurately accounting all the costs of consumerism. Capitalism is efficient at what it does, and it's the best thing going by all means, but it's only the best thing, not the perfect thing.
Which is what Bruce was saying.
This has been gone over many times here and elsewhere, and the point that trying to redo all configuration files as XML would be of very limited benefit is well taken. I do like what Apple has apparently done in terms of using XML to represent consistent meta-information for their configuration files. That makes a lot more sense to me than the SYSV-style run-level directory structure, and I hope that some brave Linux distribution grabs on to the idea.
Woosh, there goes my air deflating. ;-)
Nice to see the Anonymous Cowards sticking together, though.
Troll, troll, troll.
What warez trading on slashdot? What software pirates? What too lazy to buy software? Yeah, I guess the four+ years I've spent working on my GPL'ed project is just, sheer, rank laziness.
Puhleeze. There's a good argument to be made that lots of slashdot readers have a 'free software or die' mentality, but I've seen no one with any stature or credibility in the community assert that software that isn't free should be stolen. Yawn.
I am interested in your hit-and-run assertion that slashdot readers are violating a Biblical code of ethics, though.
A whole lot of good points in joss' post. I was very happy to see joss recommend my own indentation style, which I am very religious about.
I also especially liked joss' comments on the heavy cost of Java's immutable String class. It is disgustingly expensive to do a lot of string-type operations in Java because you have to create a new String object every time you work with a frequently changing string. They tried to make StringBuffer work efficiently with the String class.. if you extract a String from a StringBuffer, it actually re-uses the char[] array from the StringBuffer, so the overhead there is lower than you might think, but if you then try to re-use that same StringBuffer (by setting the StringBuffer size to zero and then adding new chars into it), StringBuffer behaves very poorly. It actually copies the char buffer from the old String at its full size before zero'ing it out, so if you ever extract a large String from a StringBuffer, you can get some very bad memory usage if you try to continue working with that StringBuffer thereafter.
I really love Java, and I've been working with it almost exclusively for the last four years, but there are many things like this that are only slowly being fixed. The right way to think about Java is as an operating system, with all of the complexity that that implies. You wouldn't expect a four year old operating system with all of the features that Java supports these days to be terribly mature, and Java still has a way to go.
For all of that, I do love Java, because it does work surprisingly well, all in all. My project (see my .sig) couldn't have been done with the resources we had to devote to it using anything else, and Java's precision, exception support, threading, API collection, and garbage collection make it possible to do very ambitious things with it.
Swing is getting better in 1.3, but too much of Swing is still under-specified. One problem with Swing is that all of the Swing objects are internally divided into a model and a view/controller, and a listener scheme is used to allow the view/controller to communicate with the model, and vice-versa.
One problem with that is that when you register your own code as a listener to the activity reported by the Swing component, you are just another listener as far as the view/controller is concerned. There's no way to specify that your code's listener should be called before the internal model's listener, so you can't have your code attempt to verify a proposed GUI action and reject it if it isn't viable. At least, you can't do this reliably across different kinds of Swing components, because the level of detail on the components' behavior is not specified well enough. You can go and look at the source code for the component, but since the behavior you may be depending on isn't part of the spec for the component, you can't really rely on it.
Not sure if that made sense, but basically Swing suffers a bit from the high level of complexity Sun put into it, and even with 1.3 it is still in need of more maturity. It is getting there, but Sun made their job a lot harder than it had to be by getting fancy with their pluggable look-and-feel support.
No, the whole OS wouldn't be magically made open source. If they were called on it, they would have the option of removing/rewriting that code to get out of violation of the license. There is nothing in the GPL that forces anyone to accept it, or use any code licensed under it.
All that the license does is state the terms under which code covered under the GPL can be used and distributed.
"stuff he seeded" means stuff that arose out of the ground from the seeds Carmack cast.
i.e., stuff that Carmack didn't write himself, but which was made available under the GPL by others based on his code.
ESR talks about the free rider problem in The Cathedral And The Bazaar. The whole free software movement is predicated on people being able to take more than they give back, on the assumption that enough people will give back to make it all worthwhile.
Which it is, of course, or so many wouldn't do it. Somebody ripping off GPL software in way the this anonymous coward describes is damaging not because of the free ride gotten (we *want* you to have *free* code), but because it threatens to undermine the enforceability of the GPL. I agree with the other poster.. if anyone ever catches you at your theft and can prove it on any significant scale, you and/or your corporation certainly deserve to be prosecuted.
Yup, exactly. On many platforms you get decent time slicing behavior, but the precise scheduling algorithms were left unspecified in the standard to allow compliant implementations of Java on platforms with varying thread support.
You can't depend on threads in a Java program executing in any sort of order, unless you use the synchronized keyword and the java.lang.Object.wait() and java.lang.Thread.join() methods to expressly indicate your inter-thread relationships.
On many JVM's you will get reasonable behavior if you throw a bunch of threads up in the air with the same priority level and the expectation that they'll all get a reasonable amount of time relative to each other, but that's not guaranteed in the spec.
There are many good books on Java threading, including especially Doug Lea's Concurrent Programming Java, which talks not only about Java threading, but also about all of the issues that you have to face when designing for a multithreading/multiprocessing environment. That includes deadlocks, thread starvation, resource allocation, locks, semaphores, and a whole lot more. Highly recommended.
Preemption is allowed, yes, and there are guaranteed atomic operations (reference and integer assignment, at the very least). That's why I backpedalled and said that the JLS did indeed have guarantees on thread semantics.
It just doesn't have any guarantee as to when a particular thread will be run, nor whether a thread will ever be switched unless the active thread comes to the end of its execution or to a wait() call. In practice, every JVM that I care about will do those things, and I don't bother seeking out a Palm Pilot or Win 3.1 JVM to test my code on, but in theory it's something to be aware of.