So, yeah, the copyright holder retains full control, just so long as what that copyright holder wants is for the whole world to have free access to the source code of his or her work and is free to do whatever they wish with it.
I think you may be missing one important point. The author of the code is the only person in the world *not* bound by the GPL. That is, she can distribute the binaries without giving out source code, and she can sell people the right to distribute binaries and derivative works without having to give out the source code.
Let's say company A wants to extend some open-source project, intending to make a proprietary distribution which they plan to sell. Perhaps they see the popularity of the open-source version, but also see some major improvements for which there may be a market.
Company A may be willing to pay the author for the rights to distribute the code under some license other than the GPL. In this case, it was the author's decision to GPL the code which led to it's widespread popularity, and then to the money making opportunity for the author.
IANAL, and I would be quick to concede that this scenario is probably rare. The point is tough, the author's copyright on the work is not worthless once the work is GPL'd.
I've been working with JDO essentially since it was released, and have found it to be a very effective tool. As with any technology, it takes some time to learn, and it has areas which aren't as transparent as you'd like them to be.
I have always been the "JDO-guru" for my development team. As such, I've spent a lot of time trying to smooth out the various issues we've run into, so that other members of the team can work with this technology as transparently as possible. The main thrust of this work has been to make transaction handling easier, and to deal with PersistenceManagers. My company has been generous enough to allow me to open-source this work (which I've named "Stomp"), so if you are serious about using JDO, you may want to check it out. Even if you don't use the code here, there is a page explaining how Stomp works which describes the motivation behind this toolkit, the problems we ran into, and how we solved them. You'll have to solve similar issues yourself if you use JDO, so this might be a good way to get a handle on what you'll face when you use JDO.
This stuff works very well for us, but of course has the risk of being non-standard. Even if you don't use Stomp, the ideas presented may help you use JDO more effectively.
PS Stomp is written to work with Kodo (from Solarmetric) but could easily be made to work with other JDO vendors. Write to me if you are interested.
It is a shame that software development companies do not have a legal obligation to fix significant flaws...
This lack of responsibility on the part of proprietary software developers is one of the main selling points of open source software. It's so difficult to define what constitutes a "major" problem, and what the seller should be obligated to fix.
Allowing users to steal files obviously falls on the major problem side of the line, but many other problems are in a gray area that is difficult to define. Besides this, most users find that the bugs they consider to be "major" are different than those other users might consider important, based on the way they happen to use the software.
Just another argument for using open-source software whenever you possibly can. If you discover a bug like this and the author isn't willing to fix it, you can always fix it yourself. Why would you ever want to leave this decision to someone else?
When I first came to this company, we had something like 20 IT employees... we're down to 4. Every time somebody left, the remaining folks would write a script to automate what the other guy (did)... Did it save us from hiring new people? Our HR department will tell you it did, but it's untrue. The fact is the turnaround time for IT requests has become abyssmal.
Of course. That's why these guys aren't talking about a shell script to solve the problem. They're talking about 3 billion dollar budgets to get in there and solve these issues in very robust ways. You can't just fire you IT staff and hope one guy can do the work of five... you have to have better hardware and software so that you've only got one guy's worth of work.
Can you imagine the additional testing you'd have to perform before changing a truly autonomous server? And how can you be sure that the self healing server is really healthy, or just not noticing the problem?
I imagine you'd notice it exactly the way you'd notice an unhealthy server now... things don't run, performance drops significantly, programs hang, etc. The point is to make the computer smart enough to recognize these situations and intervene to fix the problem, so that the users never realize there was anything to worry about in the first place. Contrast that with the current situation, where the computer does nothing. Someone has to realize there is a problem. Someone has to figure out what the problem is. Someone has to fix it. For companies where up-time is money, this model for computer maintenance needs to be improved.
Not likely, at least not any time soon. This article is not really describing a new phenomenon. The basic trend is all computing is to start with something that does a simple task, but is terribly difficult to install and run, and slowly make it easier. You remove the points where the end-user has to interact with the system if those interactions could have been easily figured out by the computer. This kind of optimization has been going on since computers were born, but despite all the progress, the tech industry has done nothing but grow.
So Sun and IBM are turning their attention to some particular area that needs more optimizations... this just means that in ten years, there is going to be a higher level of abstraction with the same problems to solve. I'll have to figure out how to my new McDonalds chain can just plug some new computers into a wall and have their order menus popup instantly... great for productivity, great progress, but it hardly cuts into the demand for technically skilled people.
Of course, intuitively there must be some point where the optimizations made start cutting into jobs. My feeling though is that we are still working on some of the most basic problems of computing, and it will be quite a long time before we reach the peak of this curve. I mean, a big focus of the article is how to most efficiently get data out of databases! We all take for granted that this is (currently) a very tricky issue. Imagine looking back in twenty years though... it's easy to imagine that we'll laugh at having to think about such basic issues at all. "Configuring a network? Gimme a break, piece of cake! Connect some wires and you're done!" we'll say. And yet it's easy to imagine that despite having solved all of these problems, we will still be faced with a set of complicated issues of the day to solve to utilize these features. We're still working out how to move information around efficiently. And this is just a discussion about how to move information around efficiently. We're not even getting into applications and what to do with that information once you have it.
Then someone will write an article about how IBM is focusing on the problems of that day, and is going to make it easy to handle *that* level of abstraction. We'll read that configuring interactions between networks to transparently and securely utilize excess CPU in your neighborhood, or your city, is going to be a breeeze, and we'll have this discussion all over again...
Personally, I think we should stop trying to block all these spammers. Today is a tough day for everyone. Thinking about a year ago, how the world for many of us was turned upside down... it's hard to go about your daily routine. And yet, when I arrived at work, my mailbox was crammed full of spams, just like always. While many people are coming in late or taking the day off, these spammers continue to keep me updated about new penis enlargement technologies. They put aside their personal grief and send out news of a new get-rich-quick scheme, thereby showing the terrorists that they will never win. God bless them.
I can't agree with some of them. For example:"Don't use non-standard controls".
I agree with you, however... I suspect the reason Apple makes this suggestion is that most developers over estimate their expertise in designing user interfaces. They think, "it makes sense to me" and they write a control that makes no sense at all. Their intimate familiarity with the product and it's intended use makes it difficult for them to imagine the thought process of a new user.
Designing user interfaces is pretty complicated, and requires a lot of thought. Even with this time investment, you still need to do user testing etc on your new control to see if it gets used the way you had hoped. This is true of any new interface, but especially true if that interface is full of non-standard controls. Most software products don't have the resources to devote to this aspect of development.
So yes, an intelligent design with non-standard control *can* work. But you won't go far wrong with the ones that have been carefully thought out and provided for you. As soon as the article say something like "most developers will do better with the standard controls", every developers suddenly feels like he is part of the group that doesn't fall into that category. (Everyone overestimates their own ability.)
Let's get one thing straight here... morally Verisign is completely in the clear, and this joker hiding in Mexico is completely to blame. Verisign received a forged letter, which they acted upon. They had no intent to harm the legitimate owner.
The question is, does Verisign have any legal responsibility. Ideally, no one would ever forge a letter to Verisign (or my bank), and it wouldn't be an issue. Since it's well known that seedy elements do exist in society, organizations have some obligations to guard against fraud. So what exactly should they have to do to guard against fraud?
Of course, in the end, it will come down to a judges interpretation of existing laws, and how they apply to domain names. For the purposes of this discussion though, I'd argue that they probably did enough and should not be held liable, certainly not for anything near the full 65 million dollar amount. It sounds like this occurred early in the development of the internet, at a time when procedures and practices surrounding domain names was just being thought out. Obviously now that movies about websites are being made (fear.com), the thought of turning over a domain without contacting the owner for independent verification seems negligent. And of course, they don't do that now. If someone told you about this in 1995 though, I doubt it would have seemed nearly so clear cut.
That still leaves open the question of why it took five years to get back the domain name. If Verisign was just lazy, well, that's another story, which we don't seem to have many details on. For now, I'll assume Verisign acted reasonably here (perhaps not a good assumption based on other comments about Verisign posted here...).
In short, it's an unfortunate situation (kind of... it is sex.com after all), but Verisign shouldn't have to pay.
More topics like this!
on
Haiku vs Spam
·
· Score: 1
Normally verbose,
Posters must distill their thoughts.
More topics like this!
We don't need profilers, we need coders have have that tacit knowledge of what really counts, where they should put real effort.
The problem with this statement is that most of the time a programmer's gut feelings for where bottlenecks occur turn out to be way off. I've seen this happen so many times that I just take is as fact now: trying to optimize before profiling is a waste of time.
There are two problems with optimizing too early. The first is, of course, optimizing code that isn't a bottleneck is a waste of time. Most software projects have very tight deadlines, and the time spent optimizing non-impact code is time that could have been spent developing another feature. The second problem is perhaps even worse: optimizing code usually makes it less readable, which can actually obscure the true problems and make implementing real optimizations more difficult in the future.
The best approach is to start with a clean, intuitive design. After that, don't guess at the bottlenecks. Prove it to yourself ( there are many techniques, a profiler is one option ). You will be surprised how often you're guesses are wrong, and that doing the steps in this order can produce code that is efficient and maintainable. -Eric
I'm no fan of lawyers, but it seems to me that most of the complaints here are unjustified.
First of all, who really would have gone out on their own and filed a lawsuit against AOL? Many people are complaining that consumers will only get 10$, $250... that's more money than they would have gotten without the lawsuit, and they don't have to do anything but sign onto the claim.
Besides that, one of the most important effects of such a lawsuit is to make software makers realize that they can't get away with stuff like this, which will hopefully make them a little more careful in the future. That too is a benefit that all AOL users receive for free, without having to go through the hassle of suing AOL themselves.
Finally, if you really feel the fees are unfair, you can waive your participation in the suit and take it upon yourself to sue AOL. I doubt many of the complainers on this list would turn down fifty bucks in order to pursue this option...
Slashdot Mirror
So, yeah, the copyright holder retains full control, just so long as what that copyright holder wants is for the whole world to have free access to the source code of his or her work and is free to do whatever they wish with it.
I think you may be missing one important point. The author of the code is the only person in the world *not* bound by the GPL. That is, she can distribute the binaries without giving out source code, and she can sell people the right to distribute binaries and derivative works without having to give out the source code.
Let's say company A wants to extend some open-source project, intending to make a proprietary distribution which they plan to sell. Perhaps they see the popularity of the open-source version, but also see some major improvements for which there may be a market. Company A may be willing to pay the author for the rights to distribute the code under some license other than the GPL. In this case, it was the author's decision to GPL the code which led to it's widespread popularity, and then to the money making opportunity for the author.
IANAL, and I would be quick to concede that this scenario is probably rare. The point is tough, the author's copyright on the work is not worthless once the work is GPL'd.
I've been working with JDO essentially since it was released, and have found it to be a very effective tool. As with any technology, it takes some time to learn, and it has areas which aren't as transparent as you'd like them to be.
I have always been the "JDO-guru" for my development team. As such, I've spent a lot of time trying to smooth out the various issues we've run into, so that other members of the team can work with this technology as transparently as possible. The main thrust of this work has been to make transaction handling easier, and to deal with PersistenceManagers. My company has been generous enough to allow me to open-source this work (which I've named "Stomp"), so if you are serious about using JDO, you may want to check it out. Even if you don't use the code here, there is a page explaining how Stomp works which describes the motivation behind this toolkit, the problems we ran into, and how we solved them. You'll have to solve similar issues yourself if you use JDO, so this might be a good way to get a handle on what you'll face when you use JDO.
This stuff works very well for us, but of course has the risk of being non-standard. Even if you don't use Stomp, the ideas presented may help you use JDO more effectively.
PS Stomp is written to work with Kodo (from Solarmetric) but could easily be made to work with other JDO vendors. Write to me if you are interested.
It is a shame that software development companies do not have a legal obligation to fix significant flaws...
This lack of responsibility on the part of proprietary software developers is one of the main selling points of open source software. It's so difficult to define what constitutes a "major" problem, and what the seller should be obligated to fix.
Allowing users to steal files obviously falls on the major problem side of the line, but many other problems are in a gray area that is difficult to define. Besides this, most users find that the bugs they consider to be "major" are different than those other users might consider important, based on the way they happen to use the software.
Just another argument for using open-source software whenever you possibly can. If you discover a bug like this and the author isn't willing to fix it, you can always fix it yourself. Why would you ever want to leave this decision to someone else?
When I first came to this company, we had something like 20 IT employees... we're down to 4. Every time somebody left, the remaining folks would write a script to automate what the other guy (did) ... Did it save us from hiring new people? Our HR department will tell you it did, but it's untrue. The fact is the turnaround time for IT requests has become abyssmal.
Of course. That's why these guys aren't talking about a shell script to solve the problem. They're talking about 3 billion dollar budgets to get in there and solve these issues in very robust ways. You can't just fire you IT staff and hope one guy can do the work of five... you have to have better hardware and software so that you've only got one guy's worth of work.
Can you imagine the additional testing you'd have to perform before changing a truly autonomous server? And how can you be sure that the self healing server is really healthy, or just not noticing the problem?
I imagine you'd notice it exactly the way you'd notice an unhealthy server now... things don't run, performance drops significantly, programs hang, etc. The point is to make the computer smart enough to recognize these situations and intervene to fix the problem, so that the users never realize there was anything to worry about in the first place. Contrast that with the current situation, where the computer does nothing. Someone has to realize there is a problem. Someone has to figure out what the problem is. Someone has to fix it. For companies where up-time is money, this model for computer maintenance needs to be improved.
Not likely, at least not any time soon. This article is not really describing a new phenomenon. The basic trend is all computing is to start with something that does a simple task, but is terribly difficult to install and run, and slowly make it easier. You remove the points where the end-user has to interact with the system if those interactions could have been easily figured out by the computer. This kind of optimization has been going on since computers were born, but despite all the progress, the tech industry has done nothing but grow.
So Sun and IBM are turning their attention to some particular area that needs more optimizations... this just means that in ten years, there is going to be a higher level of abstraction with the same problems to solve. I'll have to figure out how to my new McDonalds chain can just plug some new computers into a wall and have their order menus popup instantly... great for productivity, great progress, but it hardly cuts into the demand for technically skilled people.
Of course, intuitively there must be some point where the optimizations made start cutting into jobs. My feeling though is that we are still working on some of the most basic problems of computing, and it will be quite a long time before we reach the peak of this curve. I mean, a big focus of the article is how to most efficiently get data out of databases! We all take for granted that this is (currently) a very tricky issue. Imagine looking back in twenty years though... it's easy to imagine that we'll laugh at having to think about such basic issues at all. "Configuring a network? Gimme a break, piece of cake! Connect some wires and you're done!" we'll say. And yet it's easy to imagine that despite having solved all of these problems, we will still be faced with a set of complicated issues of the day to solve to utilize these features. We're still working out how to move information around efficiently. And this is just a discussion about how to move information around efficiently. We're not even getting into applications and what to do with that information once you have it.
Then someone will write an article about how IBM is focusing on the problems of that day, and is going to make it easy to handle *that* level of abstraction. We'll read that configuring interactions between networks to transparently and securely utilize excess CPU in your neighborhood, or your city, is going to be a breeeze, and we'll have this discussion all over again...
Personally, I think we should stop trying to block all these spammers. Today is a tough day for everyone. Thinking about a year ago, how the world for many of us was turned upside down... it's hard to go about your daily routine. And yet, when I arrived at work, my mailbox was crammed full of spams, just like always. While many people are coming in late or taking the day off, these spammers continue to keep me updated about new penis enlargement technologies. They put aside their personal grief and send out news of a new get-rich-quick scheme, thereby showing the terrorists that they will never win. God bless them.
using several mirrors, i'm quite sure it would be possible to make it look right.
I'd love to see a diagram of the mirror setup that will reverse the order of letters on a screen without reversing the rendering of each letter.
I can't agree with some of them. For example :"Don't use non-standard controls".
I agree with you, however... I suspect the reason Apple makes this suggestion is that most developers over estimate their expertise in designing user interfaces. They think, "it makes sense to me" and they write a control that makes no sense at all. Their intimate familiarity with the product and it's intended use makes it difficult for them to imagine the thought process of a new user.
Designing user interfaces is pretty complicated, and requires a lot of thought. Even with this time investment, you still need to do user testing etc on your new control to see if it gets used the way you had hoped. This is true of any new interface, but especially true if that interface is full of non-standard controls. Most software products don't have the resources to devote to this aspect of development.
So yes, an intelligent design with non-standard control *can* work. But you won't go far wrong with the ones that have been carefully thought out and provided for you. As soon as the article say something like "most developers will do better with the standard controls", every developers suddenly feels like he is part of the group that doesn't fall into that category. (Everyone overestimates their own ability.)
Let's get one thing straight here... morally Verisign is completely in the clear, and this joker hiding in Mexico is completely to blame. Verisign received a forged letter, which they acted upon. They had no intent to harm the legitimate owner.
The question is, does Verisign have any legal responsibility. Ideally, no one would ever forge a letter to Verisign (or my bank), and it wouldn't be an issue. Since it's well known that seedy elements do exist in society, organizations have some obligations to guard against fraud. So what exactly should they have to do to guard against fraud?
Of course, in the end, it will come down to a judges interpretation of existing laws, and how they apply to domain names. For the purposes of this discussion though, I'd argue that they probably did enough and should not be held liable, certainly not for anything near the full 65 million dollar amount. It sounds like this occurred early in the development of the internet, at a time when procedures and practices surrounding domain names was just being thought out. Obviously now that movies about websites are being made (fear.com), the thought of turning over a domain without contacting the owner for independent verification seems negligent. And of course, they don't do that now. If someone told you about this in 1995 though, I doubt it would have seemed nearly so clear cut.
That still leaves open the question of why it took five years to get back the domain name. If Verisign was just lazy, well, that's another story, which we don't seem to have many details on. For now, I'll assume Verisign acted reasonably here (perhaps not a good assumption based on other comments about Verisign posted here...).
In short, it's an unfortunate situation (kind of... it is sex.com after all), but Verisign shouldn't have to pay.
Normally verbose, Posters must distill their thoughts. More topics like this!
nfgrq? abj v unir zl irel bja ebg13 qrpbqre!
We don't need profilers, we need coders have have that tacit knowledge of what really counts, where they should put real effort.
The problem with this statement is that most of the time a programmer's gut feelings for where bottlenecks occur turn out to be way off. I've seen this happen so many times that I just take is as fact now: trying to optimize before profiling is a waste of time.
There are two problems with optimizing too early. The first is, of course, optimizing code that isn't a bottleneck is a waste of time. Most software projects have very tight deadlines, and the time spent optimizing non-impact code is time that could have been spent developing another feature. The second problem is perhaps even worse: optimizing code usually makes it less readable, which can actually obscure the true problems and make implementing real optimizations more difficult in the future.
The best approach is to start with a clean, intuitive design. After that, don't guess at the bottlenecks. Prove it to yourself ( there are many techniques, a profiler is one option ). You will be surprised how often you're guesses are wrong, and that doing the steps in this order can produce code that is efficient and maintainable.
-Eric
I'm no fan of lawyers, but it seems to me that most of the complaints here are unjustified.
First of all, who really would have gone out on their own and filed a lawsuit against AOL? Many people are complaining that consumers will only get 10$, $250... that's more money than they would have gotten without the lawsuit, and they don't have to do anything but sign onto the claim.
Besides that, one of the most important effects of such a lawsuit is to make software makers realize that they can't get away with stuff like this, which will hopefully make them a little more careful in the future. That too is a benefit that all AOL users receive for free, without having to go through the hassle of suing AOL themselves.
Finally, if you really feel the fees are unfair, you can waive your participation in the suit and take it upon yourself to sue AOL. I doubt many of the complainers on this list would turn down fifty bucks in order to pursue this option...