Descent let you move around any and all of these axes at the same time.
so:
"semicircular strafe" : 2 axes (yaw while side slipping - at least. you can actually do a great strafe with 4 axes with lots of practice)
"while also ascending" : 1 axes (in order to keep this as a 'semicircular strafe' while doing the ascention, you need to add the previously mentioned 4th axis of pitch to keep facing the target)
"and accelerating towards the target" : 1 last axis
= 5
and of course get a joystick with a twistable handle (woo, sidewinder 3d pro) or somesuch and you can roll while you do all of the above for a nice 6 axes.
My only concern is the knowledge or experience that's lost as a result
I believe this isn't so much that the knowledge is lost - it's rendered unimportant to the larger group. This allows the developers to spend their time where they would otherwise be working on or learning the intricacies of the system on more development and new ideas. (or more likely, more unreal tournament)
There will still be those people who know and work on the tool itself - but this will be a smaller subset taking their time to make everyone else's lives easier.
autoconf, install scripts, dist packages, etc, are all progressions of not requiring the developers or users to worry so much about the intricacies of development or installation, and to spend their time on things other than the tools.
A lot of people are making portends of doom if you actually pipe up and say anything yourself.
I would suggest that, rather that going alone on the limb of trying to air your own issues, you take another, safer route where your own management is concerned:
Find out what your -manager- has issues with. If your managers have been having problems with trying to get a resolution from his own superiors, then make the focus about those particular issues. If they see that the issues your manager has been telling them about are the same ones that the employees themselves are complaining about, then something is much more likely to be done about it. You also are much less likely to see any repercussions against yourself - how can your manager fire you for saying the same thing he is? (Of course, they might just get rid of both levels, but hey)
More than likely, the high-ups in the company are doing this more as a morale booster than an actual problem-fixing situation. Let them use it as such, and try to get the department's major (at least in your manager's eyes) issues addressed. They probably don't want to hear about all of your minutae, just the major things that they might actually be able to feel like they're doing something useful for on a business level, not a lower-level management level.
It also sounds like there are issues with the department that you are afraid would come back to bite you, or you wouldn't be so worried about the issue in the first place. I would take the normal approach with these problems. Go to your manager, or if there's a problem with him, go to his manager. State the problem anonymously, if nesccessary, and if you need to follow up later, perhaps phrase it as a "someone mentioned that there was this issue... do you know if anything was done about it?"
Conclusion: make a department wide concensus as to what issues need to actually be aired to the president of the company.
Let them know what you do, in a general sense, and how it helps the company, if you have to talk to them directly. If you are forced to answer 'what issues are you having?' take the route of reiterating the agreed upon issue, or use anecdotes of some simple problems that you have had and that have been solved. Something in the normal line of work... so they can understand more of what you do, but realize that you are capable and can get the job done, regardless.
click 'reply to this' to read all of the post, or here is from where I see it get cut off from:
It is similarly possible to write some or all code in a C++ class in the header file itself, though it is usually considered bad practice due to recompile issues. Java has done away with both the issues and the notion of separate header files.
More specifically: http://radio.weblogs.com/0122027/2003/04/07.html#a 12 answering this question in relation to each point:
A) this is no different than creating a C++ class from a LGPL library. Your code is yours, you are simply using the interfaces/accessors provided by the library.
answer A - unrestricted
B) this is touchier. by extending a class, you are basically creating a class that is equivalant to the original, with possible additions and modifications. However, this is being done without actually using any of the original code, so you are not actually modifying any LGPL source, and are not 'based on', but rather 'use' the original library/class. Also of note, after extending the class, the original class file can be swapped as explained above with the beginning of section 5. Java does not include any of the original 'portions' of the LGPL library in the object code compiled for an extended class, thus again, it falls in the class of code 'using' the library rather than 'based on' or containing portions of it.
answer B - unrestricted
C) in my professional (programmer) opinion, the rest of the options are merely obfuscations around the point, in case the answer to A was restricted.. again, ProxyBar is merely using the object provided and its accessors.
answer C - unrestricted
D) more obfuscation, but rather than the usage, the obfuscation here is how they retrieved the object. This concerns the distribution method, again, and thus it is not nescessary to do this. However, since the question is not whether this is needed, but if it's okay to do it, I'll answer anyway. The process used here is equivalant to the pseudo code:
org.gnu.foo.Bar obj = new org.gnu.foo.Bar();
obj.someMethod(args[0]);
which is nearly the same as A. The classes are loaded using the same class loader in both cases, because the system loader is searching for org.gnu.foo.Bar in the same places whether the import statement is used, or the Class.forName().
The only difference is that this is done at runtime -only- for this version, while the import looks up the class at compile time, as well. This means that for the import statement, insteading of assuming that your functions will exist when getMethod() returns, or that the class will even be there (notice no error checking in this and the next question), will actually check the code and ensure proper usage of functions. No actual information is stored when the compiled object/bytecode is output.
answer D - unrestricted
E) whee, more obfuscation! Same as above, except the strings are taken via the command line. The name of the class was not in question or copyrighted (maybe trademarked, but that doesn't matter in this discussion). If it were, there would be larger issues with that library than just the LGPL's interaction with Java. This question in fact has absolutely no knowledge of the LGPL'd library, and could be used to run any library, any class, any function. So it is not at all effected by the LGPL.
answer E - unrestricted
F) the org.gnu.foo.Bar in question has suddenly become an executable, not a library, and as such the license no longer has any bearing. remember from section 0: "The act of running a program using the Library is not restricted" The library has becoming it's own program using the library.
answer F - unrestricted.
That's my interpretation, and line of reasoning. Feel free to nitpick or argue against my points, I will gladly view others' reasoning.
Some of what the other posters have mentioned, I agree with -- That the decrees of those who have written the license no longer matter as far as what it 'means'. That it is for the courts to decide, and programmers to interpret how -they- think the court would interpret it when they decide whether to use a license or not.
That said, I could not find the line of thought that led Dave Turner to think that LGPL does not allow Java libraries to remain seperate (viral? parasitic?). Here is my reasoning to think otherwise, as a Java Programmer.
Remember, from section 0 of the LGPL: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted..."
We're only concerned here with what we have to/are allowed to [not] distribute and what and when we are allowed to modify.
Here's a mild stretch, but something to consider from section 2.d) "In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." A Java JAR file is essentially a ZIP file -- this could be argued to be merely a form of digital distribution medium, designed to save hardware space and costs. Thus when we distribute the JAR file including the LGPL'd library, it is no more that if we were emailing a zip, rar, or installshield including our program and LGPL'd DLL or.so's.
Section 5 (The particularly relvant one): "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
A Java program is run by invoking the java runtime on a class with a 'main' function. The only thing non-modular at that point is the class itself. All other classes can be rewritten, replaced, modified, etc, without changing the base 'executable' of the original class. Thus, all code (classes) not having anything to do with the LGPL'd code remain 'in isolation' and fall outside the scope of the LGPL.
More from Section 5: "However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library... , rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."
Key note here: Section 6 states terms for DISTRIBUTION of such executables.
Given that java doesn't create the action 'executable' until you actually attempt to run the program (until then, all compiled classes are object code), noone is ever 'distributing' a java executable. It is interpreted/linked/created/run on the user's machine. Thus, as far as distribution is concerned, we are never distributing an 'executable' containing the LGPL'd library, so section 6 never even applies to Java. At any point in the distribution, the library can be retrieved and replaced from the distributed files.
With regard to actual usage of the library in your own code, we look again at section 5:
"If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions... , then the use of the object file is unrestricted"
Using Java objects is not much different than using C++ objects. You are merely using the accessors, data structures, etc provided by the 'include' files. The 'import' command is typically interpreted as the analog to C/C++'s '#include'. Java simply does not separate the header from the object code. It is similarly possible to write some or all code in a C++ class in the
One of the points here, I think, is not just the performance gains or being the first to hit 2.2, but the fact that they have a new technique that *allows* 2.2Mhz, and supposedly fairly 'cheaply' at that.
Any new technology is good. Even if their processors aren't really competitive in the long run, their technology will trickle down, or force similar technology to be developed to compete.
The FCC isn't sueing anyone over Napster. And the condemnation isn't over the industry, but over the government's involvement in the industry.
To extend/correct your metaphor: The FCC is *requiring* that all houses be made with a Bob brand lock, because Bob has been lobbying that all houses should have locks, otherwise they won't make houses anymore.
Which of course screws over anyone wanting a house without locks, or without Bob's brand of lock, because they don't like them for one reason or another.
If it were good for the people and the companies, it would be created and bought. But it isn't for either us, or the HDTV manufacturers, and they know it. So in comes the FCC with its mandate. We get screwed. nuff said.
Robert Heinlein's _The Door Into Summer_ had an excellent "robot butler". Basically, a wheelchair , battery packs, a vacuum, and a tray. He used fictional computing components to get it to do what he needed, but I see no reason it is not reproducable with current (or even fairly old) technology. It's been almost a dream of mine to go into Mechanical Engineering (I'm a CS major at the moment) and build this thing. I'm pondering doing it with the Lego Mindstorms, for the prototype.;] Maybe someone with more time, more current skill, can get with this, sell it, make a lot of money... and send me some.:]
It is indeed sad how little the robotics field has moved forward in the past few decades, outside of the industrial area.
Slashdot Mirror
3 dimensions imply '6 axes':
3 standard directional
3 standard rotational
ie in flight:
directional: thrust/reverse, sideslip, altitude
rotational: roll, pitch, yaw
Descent let you move around any and all of these axes at the same time.
so:
"semicircular strafe" : 2 axes (yaw while side slipping - at least. you can actually do a great strafe with 4 axes with lots of practice)
"while also ascending" : 1 axes (in order to keep this as a 'semicircular strafe' while doing the ascention, you need to add the previously mentioned 4th axis of pitch to keep facing the target)
"and accelerating towards the target" : 1 last axis
= 5
and of course get a joystick with a twistable handle (woo, sidewinder 3d pro) or somesuch and you can roll while you do all of the above for a nice 6 axes.
Descent rules!
I believe this isn't so much that the knowledge is lost - it's rendered unimportant to the larger group. This allows the developers to spend their time where they would otherwise be working on or learning the intricacies of the system on more development and new ideas. (or more likely, more unreal tournament)
There will still be those people who know and work on the tool itself - but this will be a smaller subset taking their time to make everyone else's lives easier.
autoconf, install scripts, dist packages, etc, are all progressions of not requiring the developers or users to worry so much about the intricacies of development or installation, and to spend their time on things other than the tools.
A lot of people are making portends of doom if you actually pipe up and say anything yourself.
I would suggest that, rather that going alone on the limb of trying to air your own issues, you take another, safer route where your own management is concerned:
Find out what your -manager- has issues with. If your managers have been having problems with trying to get a resolution from his own superiors, then make the focus about those particular issues. If they see that the issues your manager has been telling them about are the same ones that the employees themselves are complaining about, then something is much more likely to be done about it. You also are much less likely to see any repercussions against yourself - how can your manager fire you for saying the same thing he is? (Of course, they might just get rid of both levels, but hey)
More than likely, the high-ups in the company are doing this more as a morale booster than an actual problem-fixing situation. Let them use it as such, and try to get the department's major (at least in your manager's eyes) issues addressed. They probably don't want to hear about all of your minutae, just the major things that they might actually be able to feel like they're doing something useful for on a business level, not a lower-level management level.
It also sounds like there are issues with the department that you are afraid would come back to bite you, or you wouldn't be so worried about the issue in the first place. I would take the normal approach with these problems. Go to your manager, or if there's a problem with him, go to his manager. State the problem anonymously, if nesccessary, and if you need to follow up later, perhaps phrase it as a "someone mentioned that there was this issue... do you know if anything was done about it?"
Conclusion: make a department wide concensus as to what issues need to actually be aired to the president of the company.
Let them know what you do, in a general sense, and how it helps the company, if you have to talk to them directly. If you are forced to answer 'what issues are you having?' take the route of reiterating the agreed upon issue, or use anecdotes of some simple problems that you have had and that have been solved. Something in the normal line of work... so they can understand more of what you do, but realize that you are capable and can get the job done, regardless.
My unemployed-self suggestion.
Good luck.
there seems to be a bug with slashdot (GASP)
a 12
click 'reply to this' to read all of the post, or here is from where I see it get cut off from:
It is similarly possible to write some or all code in a C++ class in the header file itself, though it is usually considered bad practice due to recompile issues. Java has done away with both the issues and the notion of separate header files.
More specifically:
http://radio.weblogs.com/0122027/2003/04/07.html#
answering this question in relation to each point:
A) this is no different than creating a C++ class from a LGPL library. Your code is yours, you are simply using the interfaces/accessors provided by the library.
answer A - unrestricted
B) this is touchier. by extending a class, you are basically creating a class that is equivalant to the original, with possible additions and modifications. However, this is being done without actually using any of the original code, so you are not actually modifying any LGPL source, and are not 'based on', but rather 'use' the original library/class. Also of note, after extending the class, the original class file can be swapped as explained above with the beginning of section 5. Java does not include any of the original 'portions' of the LGPL library in the object code compiled for an extended class, thus again, it falls in the class of code 'using' the library rather than 'based on' or containing portions of it.
answer B - unrestricted
C) in my professional (programmer) opinion, the rest of the options are merely obfuscations around the point, in case the answer to A was restricted.. again, ProxyBar is merely using the object provided and its accessors.
answer C - unrestricted
D) more obfuscation, but rather than the usage, the obfuscation here is how they retrieved the object. This concerns the distribution method, again, and thus it is not nescessary to do this. However, since the question is not whether this is needed, but if it's okay to do it, I'll answer anyway. The process used here is equivalant to the pseudo code:
org.gnu.foo.Bar obj = new org.gnu.foo.Bar();
obj.someMethod(args[0]);
which is nearly the same as A. The classes are loaded using the same class loader in both cases, because the system loader is searching for org.gnu.foo.Bar in the same places whether the import statement is used, or the Class.forName().
The only difference is that this is done at runtime -only- for this version, while the import looks up the class at compile time, as well. This means that for the import statement, insteading of assuming that your functions will exist when getMethod() returns, or that the class will even be there (notice no error checking in this and the next question), will actually check the code and ensure proper usage of functions. No actual information is stored when the compiled object/bytecode is output.
answer D - unrestricted
E) whee, more obfuscation! Same as above, except the strings are taken via the command line. The name of the class was not in question or copyrighted (maybe trademarked, but that doesn't matter in this discussion). If it were, there would be larger issues with that library than just the LGPL's interaction with Java. This question in fact has absolutely no knowledge of the LGPL'd library, and could be used to run any library, any class, any function. So it is not at all effected by the LGPL.
answer E - unrestricted
F) the org.gnu.foo.Bar in question has suddenly become an executable, not a library, and as such the license no longer has any bearing. remember from section 0: "The act of running a program using the Library is not restricted" The library has becoming it's own program using the library.
answer F - unrestricted.
That's my interpretation, and line of reasoning. Feel free to nitpick or argue against my points, I will gladly view others' reasoning.
Some of what the other posters have mentioned, I agree with -- That the decrees of those who have written the license no longer matter as far as what it 'means'. That it is for the courts to decide, and programmers to interpret how -they- think the court would interpret it when they decide whether to use a license or not.
:
.so's.
... , rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."
That said, I could not find the line of thought that led Dave Turner to think that LGPL does not allow Java libraries to remain seperate (viral? parasitic?). Here is my reasoning to think otherwise, as a Java Programmer.
Remember, from section 0 of the LGPL
"Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted..."
We're only concerned here with what we have to/are allowed to [not] distribute and what and when we are allowed to modify.
Here's a mild stretch, but something to consider from section 2.d)
"In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."
A Java JAR file is essentially a ZIP file -- this could be argued to be merely a form of digital distribution medium, designed to save hardware space and costs. Thus when we distribute the JAR file including the LGPL'd library, it is no more that if we were emailing a zip, rar, or installshield including our program and LGPL'd DLL or
Section 5 (The particularly relvant one):
"A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
A Java program is run by invoking the java runtime on a class with a 'main' function. The only thing non-modular at that point is the class itself. All other classes can be rewritten, replaced, modified, etc, without changing the base 'executable' of the original class. Thus, all code (classes) not having anything to do with the LGPL'd code remain 'in isolation' and fall outside the scope of the LGPL.
More from Section 5:
"However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library
Key note here: Section 6 states terms for DISTRIBUTION of such executables.
Given that java doesn't create the action 'executable' until you actually attempt to run the program (until then, all compiled classes are object code), noone is ever 'distributing' a java executable. It is interpreted/linked/created/run on the user's machine. Thus, as far as distribution is concerned, we are never distributing an 'executable' containing the LGPL'd library, so section 6 never even applies to Java. At any point in the distribution, the library can be retrieved and replaced from the distributed files.
With regard to actual usage of the library in your own code, we look again at section 5:
"If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions... , then the use of the object file is unrestricted"
Using Java objects is not much different than using C++ objects. You are merely using the accessors, data structures, etc provided by the 'include' files. The 'import' command is typically interpreted as the analog to C/C++'s '#include'. Java simply does not separate the header from the object code. It is similarly possible to write some or all code in a C++ class in the
One of the points here, I think, is not just the performance gains or being the first to hit 2.2, but the fact that they have a new technique that *allows* 2.2Mhz, and supposedly fairly 'cheaply' at that.
Any new technology is good. Even if their processors aren't really competitive in the long run, their technology will trickle down, or force similar technology to be developed to compete.
Hey, hey, RIAA
how many customers did you screw today?
The FCC isn't sueing anyone over Napster. And the condemnation isn't over the industry, but over the government's involvement in the industry.
To extend/correct your metaphor: The FCC is *requiring* that all houses be made with a Bob brand lock, because Bob has been lobbying that all houses should have locks, otherwise they won't make houses anymore.
Which of course screws over anyone wanting a house without locks, or without Bob's brand of lock, because they don't like them for one reason or another.
If it were good for the people and the companies, it would be created and bought. But it isn't for either us, or the HDTV manufacturers, and they know it. So in comes the FCC with its mandate. We get screwed. nuff said.
~Vic
Robert Heinlein's _The Door Into Summer_ had an excellent "robot butler". Basically, a wheelchair , battery packs, a vacuum, and a tray. He used fictional computing components to get it to do what he needed, but I see no reason it is not reproducable with current (or even fairly old) technology. It's been almost a dream of mine to go into Mechanical Engineering (I'm a CS major at the moment) and build this thing. ;] Maybe someone with more time, more current skill, can get with this, sell it, make a lot of money... and send me some. :]
I'm pondering doing it with the Lego Mindstorms, for the prototype.
It is indeed sad how little the robotics field has moved forward in the past few decades, outside of the industrial area.