Find all files last modified in jan or feb that have X in the title and move them to the X folder. Almost no gui's support that kind of selection and it's relatively straight forward in a cli. Of course that's the design difference between CLI and GUI. CLI says make the easy stuff reasonable and the hard stuff possible. GUI says make the easy stuff as easy as possible and don't support the hard.
If you had read ESR's article he also says that at this time it doesn't make sense for their product to be Open. With a bit of reading in details to be sure but the general rule is the more secret your bits are, and their code is quite special, the more sense it makes to be closed. However all secrets become less so with time and at some point in the future it may be appropriate for them to open it. They've considered the possibility and that's all a reasonable person should ask.
Linking would certainly be okay. However redistributing the result would be a clear violation of copyright. About the only thing you could buy yourself there is Linking your proprietary library, a GPL library and your GPL app together and distributing. Assuming of course that your library does not depend on the GPL Library. And a lawyer would probably be willing to argue that anyway.
Re:Breaking interoperability... again???
on
GCC 3.2 Released
·
· Score: 1
And Bugs discovered in MSVC4.2 are still in MSVC6.0. Maintaining backwards compatibility to a broken interface benefits noone.
Serialization in MFC is only nice until you uncover one of its bugs. Like a CArchive of a CList with two to the x plus 10 items is corrupt and can't be reloaded. Where x is 5 or greater by the way.
All of the techniques you listed and most other engineering problems are expressed in a procedural format. In order to use OO you would have to transform the problem into an object problem. The things that OO does really well at are things where we already think in object terms. Like GUI widgets. Most engineering problems simply aren't expressed that way. Although most problems could be rephrased that way the algorithms would necessarily not be equivalent (better or worse would require experimentation)
I've always assumed the derived work in the GPL followed Copyrights definition of derived work. Considering that it appears that Vidomi is in the clear. The derived works, the.dll(s) under contention have source code available on their site. The fact that their proprietary product cannot perform without GPL'd.dll does not make it a derived work any more than a closed work using Linux System Calls makes the work derived form Linux.
In many cases it is the "Christian" Kids who are creating the problems. The general harassment is done by those who are the norm. That's why the one's that strike out are different. The "Christians" have no tolerance for the different.
Find all files last modified in jan or feb that have X in the title and move them to the X folder. Almost no gui's support that kind of selection and it's relatively straight forward in a cli. Of course that's the design difference between CLI and GUI. CLI says make the easy stuff reasonable and the hard stuff possible. GUI says make the easy stuff as easy as possible and don't support the hard.
If you had read ESR's article he also says that at this time it doesn't make sense for their product to be Open. With a bit of reading in details to be sure but the general rule is the more secret your bits are, and their code is quite special, the more sense it makes to be closed. However all secrets become less so with time and at some point in the future it may be appropriate for them to open it. They've considered the possibility and that's all a reasonable person should ask.
Linking would certainly be okay. However redistributing the result would be a clear violation of copyright. About the only thing you could buy yourself there is Linking your proprietary library, a GPL library and your GPL app together and distributing. Assuming of course that your library does not depend on the GPL Library. And a lawyer would probably be willing to argue that anyway.
And Bugs discovered in MSVC4.2 are still in MSVC6.0. Maintaining backwards compatibility to a broken interface benefits noone.
Serialization in MFC is only nice until you uncover one of its bugs. Like a CArchive of a CList with two to the x plus 10 items is corrupt and can't be reloaded. Where x is 5 or greater by the way.
All of the techniques you listed and most other engineering problems are expressed in a procedural format. In order to use OO you would have to transform the problem into an object problem. The things that OO does really well at are things where we already think in object terms. Like GUI widgets. Most engineering problems simply aren't expressed that way. Although most problems could be rephrased that way the algorithms would necessarily not be equivalent (better or worse would require experimentation)
That link crashes IE 5.5 spectacularly.
I've always assumed the derived work in the GPL followed Copyrights definition of derived work. Considering that it appears that Vidomi is in the clear. The derived works, the .dll(s) under contention have source code available on their site. The fact that their proprietary product cannot perform without GPL'd .dll does not make it a derived work any more than a closed work using Linux System Calls makes the work derived form Linux.
In many cases it is the "Christian" Kids who are creating the problems. The general harassment is done by those who are the norm. That's why the one's that strike out are different. The "Christians" have no tolerance for the different.