When a process exits or otherwise terminates, its resources are freed.
When a thread exits but the rest of the process keeps on running, you can't automatically free any resources. You need the program to tell you what can be freed or not.
And I disagree with your disagreement. Trolltech is not using Open Source as a marketing gimmick.
First of all, their product is really Open Source and it's the same version that is sold, not some dumbed down version. Second, the money they earn from the commercial licenses is invested back into Qt, which is Open Source. That means that anyone who downloads the free version receives benefits that the paying costumers made possible.
Moreover, Trolltech employees devote part of their paid time to work on other Open Source or Free Software projects. KDE is of course the prime example, but you don't have to go far: just think of EXA (X.org project).
Finally, I fail to see the logic of not releasing a GPLed version. How would stopping a service you have no extra costs on bring any benefits? It would only make sense if the GPL product were harming Trolltech, and I don't see it that way.
And more importantly, they cannot stop releasing the GPLed version because of the Free Qt Foundation: if they don't release an Open Source version in a 12-month period, the last released version is automatically relicensed BSD.
Qt is thread-safe. What you can't do is interact with the GUI from outside the main thread, that's all.
Also, when a program crashes, it simply crashes, regardless of whether it was single-threaded or multi-threaded. Killing, cancelling or otherwise suspending threads without going through their normal exit sequence is not a good programming practice. For instance, you never know if it crashed with a locked mutex (for instance, the main event-queue mutex).
If you've ever experienced a Linux kernel-level crash, you must have noticed that you get a process stuck in D state. And you can cause other programs to get stuck too just by trying to access the resource that was locked.
One other thing: I know what I'm talking about. I designed the only multithreaded code that all KDE applications run today since KDE 3.3.
As for selecting uneditable text in dialog boxes, that's a nice feature (one that KDE has, btw). Submit it to Trolltech using the qt-bugs email address.
[...] but it looks like I'll have to move to Linux to get anything decent written.
Isn't that the whole idea?:-)
The non-commercial license is very different from the GPL.
Indeed it has to be. Just by adding a clause means it's not the same license. Add to that the fact that this is a restriction not existent on the GPL, which makes this non-commercial license GPL-incompatible. So there's no point in making a GPL-incompatible license with wording 99% similar to the GPL. Go ahead and make a different license once and for all.
He could be using klipper's (or another similar tool) selection/clipboard sync feature. What it does is that when of the two is changed, the other gets updated.
So it acts as if you didn't have clipboard and selection separation. It's intended for people who actually want to Ctrl+V some left-selected text.
Now, to bring this a bit back on-topic, there's a very interesting tool: klipper. How come Windows does have clipboard history natively?
Also, since we were talking about pasting stuff into a browser's location bar, have you ever noticed that Konqueror has a small X button to the left of the Location label? Click it to see what happens.
It's intended for easy opening an URL: click the X, paste with MMB then click the Return-key-shaped button on the right. That was the original idea. Of course, since then the idea of MMB-pasting into an empty area of the browser and have it load from Mozilla has made it into Konqueror too, which I must admit is a lot easier.
Uh... why? Unless you're talking about those companies developing their own internal apps, the licensing issue is moot. Qt is GPL, as much as the Linux kernel itself. Plus another license if you want it over GPL.
If you want to develop with Qt, we have Stallman's "Why you should license your next library GPL" discussion. Plus the fact that you can get a Qt commercial license. And the fact that intra-company deployments don't violate the GPL (this last argument is countered by some people, but FSF supports it).
If GNOME becomes the dominant desktop, I don't think it'll be Qt's license to be at fault. It is more likely to be so on account of big players pushing GNOME (Sun, Red Hat, etc.).
Besides, TrollTech isn't stupid. If the licensing was to hinder their Qt income, they'd find a way around it. I'm quite sure they'd be more than happy to see their product widely deployed around the world -- more so than it already is.
Re:I (and many brazilians) don't like the idea.
on
An RPM Port Of APT
·
· Score: 1
With one patch limit. And the generation of.deb files is not done from a central script. You might like that and I am quite sure the creators of dpkg also do. For me, it's awful. It's just an opinion.
Now, for your claim it won't work, it's unjustified. Let them at least give it a try.
Dependencies problem!? Isn't that EXACTLY was apt is supposed to do? Solve those problems? Your arguments are not making sense to me.
And last, the dependencies have to be well-thought from the vendor point of view. If Conectiva proposed using apt in their next release, they have to make it work on their repositories. If you wish to add apt to another distribution (say, you want to use original apt on Slackware or even Corel) or you want to use another source of packages, it's your own risk. They can't possibly be considered responsible for someone else's packages. Nor can Debian be considered responsible for use of apt on Slackware or Corel (that uses.debs) or use of third party packages.
Or can they?
Re:I (and many brazilians) don't like the idea.
on
An RPM Port Of APT
·
· Score: 2
They are reinventing the wheel? By adding code to apt that there wasn't there before? How come?
Granted that apt worked and works great for.deb, but it didn't for.rpm and now it does. Don't you consider that innovation?
As for changing from.rpm to.deb, it's a hell of a change. Do you think they want to dump all they've done with.rpm and switch to.deb?
And, personally, being a programmer, I like.rpm more than.deb. Why? Because of.src.rpm.
While I know this is just some kind of April Fools joke, and that the idea was to get people wondering what the hell had happened, you could have worked just a little harder and have someone translate whatever news you wanted to post. Babelfish doesn't translate to or from Portuguese very well. I am a native speaker of Portuguese and I can tell you this: the article has a lot of grammar errors to the point it doesn't make sense.
Slashdot Mirror
When a process exits or otherwise terminates, its resources are freed.
When a thread exits but the rest of the process keeps on running, you can't automatically free any resources. You need the program to tell you what can be freed or not.
And I disagree with your disagreement. Trolltech is not using Open Source as a marketing gimmick.
First of all, their product is really Open Source and it's the same version that is sold, not some dumbed down version. Second, the money they earn from the commercial licenses is invested back into Qt, which is Open Source. That means that anyone who downloads the free version receives benefits that the paying costumers made possible.
Moreover, Trolltech employees devote part of their paid time to work on other Open Source or Free Software projects. KDE is of course the prime example, but you don't have to go far: just think of EXA (X.org project).
Finally, I fail to see the logic of not releasing a GPLed version. How would stopping a service you have no extra costs on bring any benefits? It would only make sense if the GPL product were harming Trolltech, and I don't see it that way.
And more importantly, they cannot stop releasing the GPLed version because of the Free Qt Foundation: if they don't release an Open Source version in a 12-month period, the last released version is automatically relicensed BSD.
Qt is thread-safe. What you can't do is interact with the GUI from outside the main thread, that's all.
Also, when a program crashes, it simply crashes, regardless of whether it was single-threaded or multi-threaded. Killing, cancelling or otherwise suspending threads without going through their normal exit sequence is not a good programming practice. For instance, you never know if it crashed with a locked mutex (for instance, the main event-queue mutex).
If you've ever experienced a Linux kernel-level crash, you must have noticed that you get a process stuck in D state. And you can cause other programs to get stuck too just by trying to access the resource that was locked.
One other thing: I know what I'm talking about. I designed the only multithreaded code that all KDE applications run today since KDE 3.3.
As for selecting uneditable text in dialog boxes, that's a nice feature (one that KDE has, btw). Submit it to Trolltech using the qt-bugs email address.
It's not, unless you recompile kdelibs without libidn being installed.
Isn't that the whole idea?
Indeed it has to be. Just by adding a clause means it's not the same license. Add to that the fact that this is a restriction not existent on the GPL, which makes this non-commercial license GPL-incompatible. So there's no point in making a GPL-incompatible license with wording 99% similar to the GPL. Go ahead and make a different license once and for all.
He could be using klipper's (or another similar tool) selection/clipboard sync feature. What it does is that when of the two is changed, the other gets updated.
So it acts as if you didn't have clipboard and selection separation. It's intended for people who actually want to Ctrl+V some left-selected text.
Now, to bring this a bit back on-topic, there's a very interesting tool: klipper. How come Windows does have clipboard history natively?
Also, since we were talking about pasting stuff into a browser's location bar, have you ever noticed that Konqueror has a small X button to the left of the Location label? Click it to see what happens.
It's intended for easy opening an URL: click the X, paste with MMB then click the Return-key-shaped button on the right. That was the original idea. Of course, since then the idea of MMB-pasting into an empty area of the browser and have it load from Mozilla has made it into Konqueror too, which I must admit is a lot easier.
kjsembed
Yes, you've got it right: it's JavaScript. It's not yet part of KDE nor integrated, but it's coming along nicely.
Besides, there's DCOP, with which you can control your applications externally. Combined, you'll be able to do very interesting things.
Search for "kjsembed" and see its example programs to see what I mean.
Uh... why? Unless you're talking about those companies developing their own internal apps, the licensing issue is moot. Qt is GPL, as much as the Linux kernel itself. Plus another license if you want it over GPL.
If you want to develop with Qt, we have Stallman's "Why you should license your next library GPL" discussion. Plus the fact that you can get a Qt commercial license. And the fact that intra-company deployments don't violate the GPL (this last argument is countered by some people, but FSF supports it).
If GNOME becomes the dominant desktop, I don't think it'll be Qt's license to be at fault. It is more likely to be so on account of big players pushing GNOME (Sun, Red Hat, etc.).
Besides, TrollTech isn't stupid. If the licensing was to hinder their Qt income, they'd find a way around it. I'm quite sure they'd be more than happy to see their product widely deployed around the world -- more so than it already is.
Now, for your claim it won't work, it's unjustified. Let them at least give it a try.
Dependencies problem!? Isn't that EXACTLY was apt is supposed to do? Solve those problems? Your arguments are not making sense to me.
And last, the dependencies have to be well-thought from the vendor point of view. If Conectiva proposed using apt in their next release, they have to make it work on their repositories. If you wish to add apt to another distribution (say, you want to use original apt on Slackware or even Corel) or you want to use another source of packages, it's your own risk. They can't possibly be considered responsible for someone else's packages. Nor can Debian be considered responsible for use of apt on Slackware or Corel (that uses .debs) or use of third party packages.
Or can they?
Granted that apt worked and works great for .deb, but it didn't for .rpm and now it does. Don't you consider that innovation?
As for changing from .rpm to .deb, it's a hell of a change. Do you think they want to dump all they've done with .rpm and switch to .deb?
And, personally, being a programmer, I like .rpm more than .deb. Why? Because of .src.rpm.
While I know this is just some kind of April Fools joke, and that the idea was to get people wondering what the hell had happened, you could have worked just a little harder and have someone translate whatever news you wanted to post. Babelfish doesn't translate to or from Portuguese very well. I am a native speaker of Portuguese and I can tell you this: the article has a lot of grammar errors to the point it doesn't make sense.