The GPL doesn't say that you can't create derivative works without giving them away. It says you can't *distribute* derivative works without giving them away.
If you're building proprietary software for use internally by the company, then they are not, legally, distributing it! In effect, it is purely free, so long as you don't distribute your derivative works.
When you develop a piece of software that uses someone elses library, you have to observe the licensing terms of that other library. That's the way it is.
When you write a piece of software that uses windows include files, you are obligated to follow the license terms of those.
That much is perfectly clear. You may not like it, but that's just tough. Copyright law is pretty darned clear about it, and alas, your opinion doesn't end up counting for squat in court. (Seriously - there are some very depressing legal precedents which ultimately mean that our opinions or interpretations of a license are worth less than nothing.)
Where it becomes messy is in the definition of a derived work. And the linked article is almost certainly wrong about how to define that.
For example: a library that provides a binding for gtk to a new programming language is probably legally a derived work of gtk. Even though it doesn't modify a single line of code from gtk, and only links against it.
The key question is always how far can you go, as the client of a library, before you become a derivative. And the only answer there comes from talking to a knowledgeable lawyer, following thier advice, and hoping for the best.
I've got ulnar nerve trouble related to RSI. For a while the pain had gotten so bad that I'd sit at night with my wrists propped up with a stack of pillows because anyting else was too painful.
The Kinesis didn't solve my problem, but it reduced it to a manageable level. Moving the control and enter keys onto the makes a huge difference, and the contour where your wrists aren't rotated and stressed just sitting on the home row almost instantly cut a lot of my pain.
The rest of my problem comes down to behavior modification, which I haven't been entirely successful at.
Actually, I thought that worked pretty poorly. I read the whole series in sequence last summer, and found then when you read them back to back, a lot of it doesn't hang together well.
In particular, there's a pretty rough disconnect between "Dune" and the first sequel; and then there's another harsh disconnect between "Dune Messiah" and "Children of Dune". Once you get past that, it mostly hangs together pretty well. But the start is really very bumpy and inconsistent.
Subversion is, basically, changeset based. Their storage model is a bit.... wierd. But they capture the set of changes in a checkin as a single, atomic change unit.
On the other hand, when we started implementing Stellation, we used PRCS. To say that it's a frustating, annoying, glitchy mess is an epic understatement. When we finally moved to self-hosting (inside IBM; we don't yet have strong enough access control to put up a public Stellation server, so we shadow our internal repos to an external CVS for the moment), it was an enormous relief.
PRCS generates thousands upon thousands of unnecessary questions, phrased in obtuse and easily misinterpreted ways. It requires you to manually maintain the map between filenames and repository artifacts, by manually editing a cryptic configuration file. It constantly mucks up that configure file, adding hundreds of carriage returns for no apparent reason. Echh. The versioning model is very nice; the implementation is solid, but frustrating.
That's part of what we're doing in Stellation. Our basic view is that source files combine storage and organization in unfortunate ways. So we want to break that linkage: code lives in the database, stored as small pieces. Pseudo-files are generated to give you organizational views of the system. Because storage and organization are distinct, there's no reason that a given chunk of code can't be viewed in multiple pseudo-files.
The big catch is that there are an awful lot of very useful tools out there, and they're not going to give up their filesystems overnight. So you need to be able to both discard the file notion when it's appropriate, but at the same time to preserve the ability to use a filesystem when necessary. Stellation pseudo files can always be exported into a real filesystem to work with tools that don't understand it's database storage model.
Envy was one of the major motivators that led me to start Stellation.
I loved Envy in theory, but hated it in practice. Fine-grained versioning and locking is a truly wonderful thing. But being locked into exactly the views that they happened to build in to VA Java was incredibly frustrating. Not being able to really use JavaCC or Antlr along with my Java code really bugged me. Not being able to use emacs really bugged me. The overly strict management stuff really bugged me. There were gems of brilliance scattered around the system, but the overall realization of it drove me up a tree.
Stellation tries to do many of the same things, but without getting caught up in the whole "I control the Universe" assumption that make Envy so frustrating. We're also trying to take things much further that Envy did - giving more flexible ways of locking small pieces, providing better tools for coordinating programmers, allowing programmers to quickly and easily generate custom views of their code, and allowing external tools to be tied seamlessly into the system.
Take a look at Stellation. Our long-term goal is to fundamentally change the way that programmers view and store thier code.
If you want to use a CVS lookalike, Stellation can do that. But in its full-blown form, source files become an illusion. You can still edit them, save them, etc... But the versioning is happening at a finer grain. Refactor your code to move a method, and Stellation preserves the full history of that method. Need to look at a bunch of code that's scattered through many files? Issue a query to generate a file containing exactly what you want to see. Edit it there, and then when you commit the change, it shows up in all of the other files where that code lives.
I agree completely. One of the goals of the system that I'm working on (Stellation) is the integration of pluggable semantic components for particular programming languages.
Our basic idea is that if you don't know the language that something is written in, you treat it as text, providing all of the capabilities of a system like ClearCase. But if you do know the language, take advantage of that support, and provide extra, language specific capabilities.
About two years ago, I interviewed for another job, got an offer, and told my current employer that I was leaving. I actually didn't really want a counter-offer.
But they made one anyway. And I ended up taking it. And it was probably the smartest decision I ever made.
The catch is, money wasn't really an issue. There were other things I was unhappy about at work. I wasn't planning on leaving because of money - in fact, the new job was a moderate pay-*cut*, with very small chances of actually paying off financially in the long run.
But I'm just not a money-obsessed person. I'm payed very well, and to me, once you reach the point where you can afford a car and a house and a reasonable amount of entertainment, more money just doesn't matter.
So the counter-offer didn't really involve any money. The only financial component was that the new job offer came the week before we were supposed to be told about our regular raises, and mine was impressive. But the only reason that mattered was because of what it told me about what my management thought of my work, which hadn't been communicated very clearly before that.
So the counter offer was an offer to change some of the things about my job that I was unhappy about. And I ended up taking them up on it.
I couldn't be happier with my job now. And my management seems very happy with me, as well. It's been over two years, so I'm pretty sure that it wasn't just a ruse to keep me long enough to let them fire me.
So... The moral of the story: if you're leaving a job that you're happy with, and that you're getting payed fairly for, counter-offers are probably a bad deal -- for exactly the reasons detailed in the parent post.
On the other hand, if you're unhappy with your job, sometimes the outside offer will get people to take your unhappiness seriously. Sometimes it's the squeaky wheel that gets the grease.
But finally: never use a job offer as leverage if you don't really intend to take it. I gave notice at my current job, and I was 100 percent serious about leaving. If you make the threat to leave, and you're not serious, you're probably going to wind up unemployed.
Unfortunately, you're right about UML. In fact, I'd say that you're being too mild. I wouldn't spend much time trying to learn it in any great detail, nor would I spend much work time trying to model a system in UML.
As an experiment, I tried to describe the design of my current system (basically a CVS replacement) using plain text, UML, and a formal specification language called Z.
Of the three, the Z had the wonderful property that it made several crucial design errors absolutely crystal clear, and led to fixing the design, and saving months of programming effort.
The text had the advantage that people could sit down and read it, and get a basic idea of what was going on. It wasn't very precise, and it was ambiguous in places, but it's enough to give people some idea of what was going on.
The UML was utterly useless. It captured none of the interesting properties of the system. It had no explanatory value. It had no analytical value. It was harder to understand than the text, and carried far less information; and the semantics of UML are so ill-defined that it had absolutely no precision. Even after added some specification clauses uses OCL, it was still an utter waste of time.
The only UML diagram that I've seen that had any value was a Rose diagram used as an explanatory aid for the DeltaV draft standard. The standard, by necessity, was written in such dense standardese, with so many inter-referrences with other standards, that it was very difficult to comprehend, and the diagram at least gave a canonical view of the basic entities and some notion of what the relationships between them were.
While I agree with you in principal that there are cases where open-source makes it impossible to make money producing something, you chose a rather poor example for your argument.
Several companies have produced "value-added" versions of Apache, and make a lot of money selling them. For instance, IBM's Websphere platform is nothing more than an extended version of Apache. And they make quite a lot of money on it. People are willing to pay for the combination of guaranteed support and added features.
The system does not go through all of the directories in the path every time you type a command. No shell that I know of is stupid enough to do that.
Shells do a lot of cacheing. The most common strategy these days is to automatically regenerate the path cache every time you change your cache. Many shells also have a way of manually directing it to rebuild it's cache.
With an intelligently designed cache, the memory use difference between cacheing binaries from a small number of huge directories, and a huge number of small directories is small to zero.
That said, I still disagree with Mosfet. I've also done time as a sysadmin. Personally, I think that having the binaries stored together is preferable, because I'm capable of using a package manager to manage my applications; but many of my users find it extremely difficult to deal with paths. (Not to mention the degree of sensitivity it produces when you change a system. If I use RPM to install a new version of something, then the RPM database id modified with information about the new version. If I install something in a way that modifies the directory heirarchy, then I have to make sure that every user of my system correctly modifies their path.
Personally, I think RPM style package managers are a huge step forwards, and they make the admins job a lot easier. Why should I care that there are thousands of files in my/usr/bin, as long as I have a useful tool for managing them?
Now, data files are a different matter... But they get separate directories in the current style. So that's not a problem.
Grrr... You're making one of my least favorite ignorant twit mistakes.
Back in grad school, I used to read comp.theory, and at least once a month, we'd have some jerk post to the newsgroup "NP solved!", followed by some stupid, exponential time algorithm for 3-SAT or something. Invariably, the poster would spend thousands of lines defending his supreme genius in being the person who solved an NP complete problem!
NP complete does not mean unsolvable. It means slow.
Roughly speaking, NP problems are problems for which their is no non-exponential time solution known, but for which solutions can be tested for correctness in polynomial time. (To translate, exponential time means that the time to compute the solution for a problem of size n is bounded by x^n for some n. Polynomial time means that the time for a problem of size n can be bounded by some polynomial of n.)
The travelling salesman is a classic example of an NP problem. Given a set of cities, and the distance between any two cities, compute the shortest route that visits each city once. It's a trivial problem, but as far as anyone knows, it's not possible to write a program that quickly determines the correct shortest route in every case.
NP complete problems are problems which have the fascinating problem that *if* you found a polynomial time solution for that problem, then you would have found a polynomial time solution for all NP problems.
The travelling salesman is, if I recall correctly, slightly *worse* than NP complete. Again, if I recall correctly, if you have a P-time solution to the TSP, then you provably have a P-time solution to any NP-complete problem; but if you have a P-time solution for an NP-complete problem, that doesn't mean that you have a P-time solution to the TSP. The proof is actually quite interesting, so go get an algorithm textbook, and read it. I'd suggest the Corman, Leiserson and Rivest text, which is my personal favorite.
There are perfect, well known solutions for all of the classic NP complete problems. They're just exponential time. (For instance, for the travelling salesman: enumerate all possible routes; compute the length of each route; and pick the shortest one.)
I agree completely with everything you said; it's the main reason that I'm working so hard to get permission to open-source my own project.
My argument was with the idea that the reason that IBM is opening a large system like Eclipse is because they want to take advantage of free labor. Anyone who open-sources a system in the expectation of lowering costs through free labor is in for a big shock: the open-source contributors will work on what matters to them, not what matters to you.
I don't mean that as a criticism - it's what makes open systems so succesful and so useful. But it does mean that any effort to lower costs through open-source is doomed.
First, SWT is cross-platform. It's based on a very small native core, which is apparently quite easy to port to new platforms.
Second, porting the system to AWT, aside from the sheer complexity of the task, would entirely defeat the purpose of why the wrote SWT to begin with.
AWT/Swing is slow. There is no way around that. The way that it's implemented, it will inevitably be extremely slow compared to native UIs. For large, complex UIs, you really need to use Swing; at the same time, the larger and more complex the UI, the worse Swing's performance gets.
The Eclipse team, after doing a lot of work writing IDEs in Java, concluded that no matter how much effort you spend on tuning, and no matter how good a JIT you have running in your JVM, the performance will not be acceptable.
Eclipse performance is wonderful. I've been using it regularly for about two weeks, and I still keep getting this shock every time I remember that the thing is written in Java. You'll never get that in an AWT port - you'll just get the same slow, ugly stuff that people normally associate with Java.
Yes, that's exactly what it means. The SWT piece of Eclipse is completely separable (it's a JAR file plus a dll). And since it's open-source, you can just take it out of Eclipse, and incorporate it into your own applications like any other library. Bingo: fast, pretty UIs under Java.
You're mistaken there. I'm using it right now (in a window in my next workspace), and I'm using on files in-place in their original directory. When you create a project in the Eclipse Java tools, you can select a location where it will live. The default location is inside of Eclipse's project directory, but you can change that.
Eclipse does not use the old VA Java repository. It uses a filesystem to store its files. For now, it plays nice with CVS, and with ClearCase. It's got some pretty nifty stuff to reconstruct method level version histories, so that it can give you UI support similar to what it had before, but without the repository.
In the near future, given any luck, my group will be releasing an tool (open-source, we hope) for code storage which will, eventually, let you do things like the old VA Java repository, but without locking you in. You'll still be able to use source files, without the old VAJ import/export hell. Info at our website.
Wrong... Tons of people are, in fact, using Java. Particularly on large servers.
And Eclipse is the platform that all of us in IBM are using for developing all of our programming tools for the foreseeable future. We're pretty committed to this thing.
And if you take a look at it, you might just
be surprised. I certainly never believed that a
UI written in Java could possibly be that fast.
I'm pretty sure that the "public domain" was a newspaper-speak error. I don't know which, but
it'll be either GPL or CPL. (CPL is IBM's Common
Public License...)
Slashdot Mirror
The GPL doesn't say that you can't create derivative works without giving them away. It says you can't
*distribute* derivative works without giving them
away.
If you're building proprietary software for use internally by the company, then they are not, legally, distributing it! In effect, it is purely free, so long as you don't distribute your derivative works.
-Mark
When you develop a piece of software that uses someone elses library, you have to observe the licensing terms of that other library. That's the way it is.
When you write a piece of software that uses windows include files, you are obligated to follow the license terms of those.
That much is perfectly clear. You may not like it, but that's just tough. Copyright law is pretty darned clear about it, and alas, your opinion doesn't end up counting for squat in court. (Seriously - there are some very depressing legal precedents which ultimately mean that our opinions or interpretations of a license are worth less than nothing.)
Where it becomes messy is in the definition of a derived work. And the linked article is almost certainly wrong about how to define that.
For example: a library that provides a binding for gtk to a new programming language is probably legally a derived work of gtk. Even though it doesn't modify a single line of code from gtk, and only links against it.
The key question is always how far can you go, as the client of a library, before you become a derivative. And the only answer there comes from talking to a knowledgeable lawyer, following thier advice, and hoping for the best.
-Mark
The Kinesis is an absolute godsend.
I've got ulnar nerve trouble related to RSI. For a while the pain had gotten so bad that I'd sit at night with my wrists propped up with a stack of pillows because anyting else was too painful.
The Kinesis didn't solve my problem, but it reduced it to a manageable level. Moving the control and enter keys onto the makes a huge difference, and the contour where your wrists aren't rotated and stressed just sitting on the home row almost instantly cut a lot of my pain.
The rest of my problem comes down to behavior modification, which I haven't been entirely successful at.
-Mark
Actually, I thought that worked pretty poorly. I read the whole series in sequence last summer, and found then when you read them back to back, a lot of it doesn't hang together well.
In particular, there's a pretty rough disconnect between "Dune" and the first sequel; and then there's another harsh disconnect between "Dune Messiah" and "Children of Dune". Once you get past that, it mostly hangs together pretty well. But the start is really very bumpy and inconsistent.
-Mark
A few more artist-run labels:
- Compass Records, owned by Allison Brown (former
banjo player for Allison Krause and Union Station, currently fronting her own Jazz quartet.)
- Discipline Global Mobile, owned by Robert Fripp (founder of King Crimson).
- Realworld, run by Peter Gabriel.
Subversion is, basically, changeset based. Their storage model is a bit.... wierd. But they capture the set of changes in a checkin
as a single, atomic change unit.
On the other hand, when we started implementing Stellation, we used PRCS. To say that it's a frustating, annoying, glitchy mess
is an epic understatement. When we finally moved to self-hosting
(inside IBM; we don't yet have strong enough access control to
put up a public Stellation server, so we shadow our internal
repos to an external CVS for the moment), it was an enormous
relief.
PRCS generates thousands upon thousands of unnecessary questions,
phrased in obtuse and easily misinterpreted ways. It requires you
to manually maintain the map between filenames and repository
artifacts, by manually editing a cryptic configuration file. It
constantly mucks up that configure file, adding hundreds of carriage
returns for no apparent reason. Echh. The versioning model
is very nice; the implementation is solid, but frustrating.
-Mark
That's part of what we're doing in Stellation. Our basic
view is that source files combine storage and organization
in unfortunate ways. So we want to break that linkage: code
lives in the database, stored as small pieces. Pseudo-files
are generated to give you organizational views of the system.
Because storage and organization are distinct, there's
no reason that a given chunk of code can't be viewed in multiple
pseudo-files.
The big catch is that there
are an awful lot of very useful tools out there, and they're
not going to give up their filesystems overnight. So you need
to be able to both discard the file notion when it's appropriate,
but at the same time to preserve the ability to use a filesystem
when necessary. Stellation pseudo files can always be exported
into a real filesystem to work with tools that don't understand
it's database storage model.
-Mark
Envy was one of the major motivators that led me to start Stellation.
I loved Envy in theory, but hated it in practice. Fine-grained
versioning and locking is a truly wonderful thing. But being
locked into exactly the views that they happened to build in to
VA Java was incredibly frustrating. Not being able to really
use JavaCC or Antlr along with my Java code really bugged me.
Not being able to use emacs really bugged me. The overly
strict management stuff really bugged me. There were gems of
brilliance scattered around the system, but the overall
realization of it drove me up a tree.
Stellation tries to do many of the same things, but without
getting caught up in the whole "I control the Universe" assumption
that make Envy so frustrating. We're also trying to take things
much further that Envy did - giving more flexible ways of locking
small pieces, providing better tools for coordinating programmers,
allowing programmers to quickly and easily generate custom
views of their code, and allowing external tools to be tied
seamlessly into the system.
-Mark
In fact, most of the commercial SCM tools do exactly that. ClearCase
and Perforce both use databases for storage at the back end. So
does Stellation.
-Mark
Take a look at Stellation.
Our long-term goal is to fundamentally
change the way that programmers view and store thier code.
If you want to use a CVS lookalike, Stellation can do that. But
in its full-blown form, source files become an illusion. You can
still edit them, save them, etc... But the versioning is happening
at a finer grain. Refactor your code to move a method, and Stellation
preserves the full history of that method. Need to look at a bunch
of code that's scattered through many files? Issue a query to generate
a file containing exactly what you want to see. Edit it there,
and then when you commit the change, it shows up in all of the
other files where that code lives.
-Mark
I agree completely. One of the goals of the system that I'm
working on (Stellation) is the integration of pluggable
semantic components for particular programming languages.
Our basic idea is that if you don't know the language that
something is written in, you treat it as text, providing all
of the capabilities of a system like ClearCase. But if you
do know the language, take advantage of that support, and
provide extra, language specific capabilities.
-Mark
Just a minor correction: Stellation is now out, open-source. The
correct website for our open-source project is
http://www.eclipse.org/stellation.
I've got a very different point of view.
About two years ago, I interviewed for another job, got an offer, and told my current employer that I was leaving. I actually didn't really want a counter-offer.
But they made one anyway. And I ended up taking it. And it was probably the smartest decision I ever made.
The catch is, money wasn't really an issue. There were other things I was unhappy about at work. I wasn't planning on leaving because of money - in fact, the new job was a moderate pay-*cut*, with very small chances of actually paying off financially in the long run.
But I'm just not a money-obsessed person. I'm payed very well, and to me, once you reach the point where you can afford a car and a house and a reasonable amount of entertainment, more money just doesn't matter.
So the counter-offer didn't really involve any money. The only financial component was that the new job offer came the week before we were supposed to be told about our regular raises, and mine was impressive. But the only reason that mattered was because of what it told me about what my management thought of my work, which hadn't been communicated very clearly before that.
So the counter offer was an offer to change some of the things about my job that I was unhappy about. And I ended up taking them up on it.
I couldn't be happier with my job now. And my management seems very happy with me, as well. It's been over two years, so I'm pretty sure that it wasn't just a ruse to keep me long enough to let them fire me.
So... The moral of the story: if you're leaving a job that you're happy with, and that you're getting payed fairly for, counter-offers are probably a bad deal -- for exactly the reasons detailed in the parent post.
On the other hand, if you're unhappy with your job, sometimes the outside offer will get people to take your unhappiness seriously. Sometimes
it's the squeaky wheel that gets the grease.
But finally: never use a job offer as leverage if you don't really intend to take it. I gave notice at my current job, and I was 100 percent serious about leaving. If you make the threat to leave, and you're not serious, you're probably going to wind up unemployed.
-Mark
Unfortunately, you're right about UML. In fact, I'd say that you're being too mild. I wouldn't spend much time trying to learn it in any great detail, nor would I spend much work time trying to model a system in UML.
As an experiment, I tried to describe the design of my current system (basically a CVS replacement) using plain text, UML, and a formal specification language called Z.
Of the three, the Z had the wonderful property that it made several crucial design errors absolutely crystal clear, and led to fixing the design, and saving months of programming effort.
The text had the advantage that people could sit down and read it, and get a basic idea of what was going on. It wasn't very precise, and it was ambiguous in places, but it's enough to give people some idea of what was going on.
The UML was utterly useless. It captured none of the interesting properties of the system. It had no explanatory value. It had no analytical value. It was harder to understand than the text, and carried far less information; and the semantics of UML are so ill-defined that it had absolutely no precision. Even after added some specification clauses uses OCL, it was still an utter waste of time.
The only UML diagram that I've seen that had any value was a Rose diagram used as an explanatory aid for the DeltaV draft standard. The standard, by necessity, was written in such dense standardese, with so many inter-referrences with other standards, that it was very difficult to comprehend, and the diagram at least gave a canonical view of the basic entities and some notion of what the relationships between them were.
While I agree with you in principal that there are cases where open-source makes it impossible to make money producing something, you chose a rather poor example for your argument.
Several companies have produced "value-added" versions of Apache, and make a lot of money selling them. For instance, IBM's Websphere platform is nothing more than an extended version of Apache. And they make quite a lot of money on it. People are willing to pay for the combination of guaranteed support and added features.
The system does not go through all of the directories in the path every time you type a command. No shell that I know of is stupid enough to do that.
Shells do a lot of cacheing. The most common strategy these days is to automatically regenerate the path cache every time you change your cache. Many shells also have a way of manually directing it to rebuild it's cache.
With an intelligently designed cache, the memory use difference between cacheing binaries from a small number of huge directories, and a huge number of small directories is small to zero.
That said, I still disagree with Mosfet. I've also done time as a sysadmin. Personally, I think that having the binaries stored together is preferable, because I'm capable of using a package manager to manage my applications; but many of my users find it extremely difficult to deal with paths. (Not to mention the degree of sensitivity it produces when you change a system. If I use RPM to install a new version of something, then the RPM database id modified with information about the new version. If I install something in a way that modifies the directory heirarchy, then I have to make sure that every user of my system correctly modifies their path.
Personally, I think RPM style package managers are a huge step forwards, and they make the admins job a lot easier. Why should I care that there are thousands of files in my /usr/bin, as long as I have a useful tool for managing them?
Now, data files are a different matter... But they get separate directories in the current style. So that's not a problem.
The Halting problem is not NP complete. It's
unsolvable.
Why is it so friggin' hard to see the difference? It's it totally obvious that the travelling salesman problem is simple to solve?
Back in grad school, I used to read comp.theory, and at least once a month, we'd have some jerk post to the newsgroup "NP solved!", followed by some stupid, exponential time algorithm for 3-SAT or something. Invariably, the poster would spend thousands of lines defending his supreme genius in being the person who solved an NP complete problem!
NP complete does not mean unsolvable. It means slow.
Roughly speaking, NP problems are problems for which their is no non-exponential time solution known, but for which solutions can be tested for correctness in polynomial time. (To translate, exponential time means that the time to compute the solution for a problem of size n is bounded by x^n for some n. Polynomial time means that the time for a problem of size n can be bounded by some polynomial of n.)
The travelling salesman is a classic example of an NP problem. Given a set of cities, and the distance between any two cities, compute the shortest route that visits each city once. It's a trivial problem, but as far as anyone knows, it's not possible to write a program that quickly determines the correct shortest route in every case.
NP complete problems are problems which have the fascinating problem that *if* you found a polynomial time solution for that problem, then you would have found a polynomial time solution for all NP problems.
The travelling salesman is, if I recall correctly, slightly *worse* than NP complete. Again, if I recall correctly, if you have a P-time solution to the TSP, then you provably have a P-time solution to any NP-complete problem; but if you have a P-time solution for an NP-complete problem, that doesn't mean that you have a P-time solution to the TSP. The proof is actually quite interesting, so go get an algorithm textbook, and read it. I'd suggest the Corman, Leiserson and Rivest text, which is my personal favorite.
There are perfect, well known solutions for all of the classic NP complete problems. They're just exponential time. (For instance, for the travelling salesman: enumerate all possible routes; compute the length of each route; and pick the shortest one.)
I agree completely with everything you said; it's the main reason that I'm working so hard to get permission to open-source my own project.
My argument was with the idea that the reason that IBM is opening a large system like Eclipse is because they want to take advantage of free labor. Anyone who open-sources a system in the expectation of lowering costs through free labor is in for a big shock: the open-source contributors will work on what matters to them, not what matters to you.
I don't mean that as a criticism - it's what makes open systems so succesful and so useful. But it does mean that any effort to lower costs through open-source is doomed.
First, SWT is cross-platform. It's based on a very small native core, which is apparently quite easy to port to new platforms.
Second, porting the system to AWT, aside from the sheer complexity of the task, would entirely defeat the purpose of why the wrote SWT to begin with.
AWT/Swing is slow. There is no way around that. The way that it's implemented, it will inevitably be extremely slow compared to native UIs. For large, complex UIs, you really need to use Swing; at the same time, the larger and more complex the UI, the worse Swing's performance gets.
The Eclipse team, after doing a lot of work writing IDEs in Java, concluded that no matter how much effort you spend on tuning, and no matter how good a JIT you have running in your JVM, the performance will not be acceptable.
Eclipse performance is wonderful. I've been using it regularly for about two weeks, and I still keep getting this shock every time I remember that the thing is written in Java. You'll never get that in an AWT port - you'll just get the same slow, ugly stuff that people normally associate with Java.
Yes, that's exactly what it means. The SWT piece of Eclipse is completely separable (it's a JAR file plus a dll). And since it's open-source, you can just take it out of Eclipse, and incorporate it into your own applications like any other library. Bingo: fast, pretty UIs under Java.
You're mistaken there. I'm using it right now (in a window in my next workspace), and I'm using on files in-place in their original directory. When you create a project in the Eclipse Java tools, you can select a location where it will live. The default location is inside of Eclipse's project directory, but you can change that.
Eclipse does not use the old VA Java repository. It uses a filesystem to store its files. For now, it plays nice with CVS, and with ClearCase. It's got some pretty nifty stuff to reconstruct method level version histories, so that it can give you UI support similar to what it had before, but without the repository.
In the near future, given any luck, my group will be releasing an tool (open-source, we hope) for code storage which will, eventually, let you do things like the old VA Java repository, but without locking you in. You'll still be able to use source files, without the old VAJ import/export hell. Info at our website.
Wrong... Tons of people are, in fact, using Java. Particularly on large servers.
And Eclipse is the platform that all of us in IBM are using for developing all of our programming tools for the foreseeable future. We're pretty committed to this thing.
And if you take a look at it, you might just
be surprised. I certainly never believed that a
UI written in Java could possibly be that fast.
I'm pretty sure that the "public domain" was a newspaper-speak error. I don't know which, but
it'll be either GPL or CPL. (CPL is IBM's Common
Public License...)