I don't see why the DRAM couldn't be integrated in the chip as well (except for the limited space on the chip, of course). One could even think of an integrated Flash drive. Of course you'll still need cables.
Even if MS could kill commercial Linux, it will not be able to kill Linux. Linux survived quite some time without business. Yes, development will slow down, but there will be no way it will be killed. That's the big advantage of FOSS: When IBM stopped supporting OS/2, it basically was dead. If IBM stops supporting Linux, then it will still exist and continue to be developed.
Maybe software pirates as a whole should get MS to sign a deal with them to not sue over distribution of pirated software and to provide protection to those they serve it too. But what would they have to offer? Not charging Microsoft for their distribution service for MS software?
As long as you are an end user (i.e. you neither modify nor redistribute the code), you are not affected by either license. You can use the code on your computer any way you like, no matter if it's GPLv2ed, GPLv3ed or BSDed. Add to that that most private end users don't care a shit anyway about licensing, and I don't see your lack of adoption.
Those affected by the GPLv2 vs. GPLv3 are those who develop software derived from other GPLed software, those who redistribute GPLed software (e.g. by selling CD-ROMs or by selling hardware with GPLed software installed), and those who want to GPL their software, but use certain non-GPLed libraries (because the GPLv3 is compatible to more of them).
And the resentment isn't in using GPLed software. It is in being forced into using GPLv3 software.
Nobody is forced to use GPLv3 software. If your current GPLv2 software does everything you need, just continue using it. There's no termination (unless you violate GPLv2, of course). Of course should you want to have some of the features future GPLv3ed versions offer, then you'll have to decide if you change to the new GPLv3 version, or if you dislike the GPLv3 so much that you don't use that new version anyway. But it's your choice (you could even decide to make a GPLv2 fork by implementing those features yourself into the GPLv2 version).
But I'm not worried about what is done with my code; which is why I'm not moving to v3.
Well, if you don't care what is done with your code, the BSD license is probably your best option. The advantage over public domain is that it explicitly disclaims any warranty (i.e. if someone tries your code and it doesn't work as expected and causes damage, they can't successfully sue you).
As a developer releasing code, GPL v3 doesn't give me more "freedom", it gives me more "control".
That's because GPL is not about the freedom for the initial developer (the copyright law already gives the initial developer all freedoms he ever needs; except that patents may undermine them, but there's nothing a license can change about that), the GPL is about the freedom of those who receive the code.
The GPL isn't free. BSD isn't free. They're both "copyleft" licenses.
No, BSD is no copyleft. You can easily take BSD code and release it under a different, even proprietay license. You just have to keep the copyright claim intact (and the original BSD license also had that advertising clause). In short, as long as you are not lying about who wrote it, you may use and relicense it any way you want.
First note, that generally the most money is not made with private users, but with companies.
Now imagine your business e.g. depends vitally on Linux, but there happens to be a kernel bug which critically affects your business. If you just downloaded it from the net, you are on your own. Of course the developers will care about the bug, and eventually fix it, but if your business critically depends on it, an answer like "Next week I'll probably have time to look into that" will not be acceptable to you. You need the fix, and you need it as fast as possible. And that's what you pay for. You don't pay for the right to run it on your computers, you pay for the guarantee that if something goes wrong, there's someone who cares about that, and whom you can blame if it doesn't work out as expected (don't underestimate the importance of the latter point!).
Ok, but if you write the code, anyone can step in and offer service for it, right? Right. But the author of the code has an invaluable advantage: No one would doubt that he knows the code better than anyone else. So if something goes wrong, whom would you trust more to be able to fix it, the original author or some random other person? Well, if it's not the author, you'd probably better stay away from the code at all.
We warrant that this program, when run unmodified on a computer which is operating properly, will do what the source code says it will do.
You'll probably want to restrict this warranty a bit further. After all, can you say for sure that your compiler doesn't have a bug, which causes the executable to misbehave in certain uncommon situations, despite the source being correct?
The usual warranty I see on software products is that the disk works at least for some (usually quite short) time. So maybe you should simply provide the warranty that the archives can be unpacked, provided it is attempted on a working computer with appropriate, working unpacking software, and there's still enough disk space free on the destination drive.
If someone complains because he got a corrupted archive, then you simply can mail them an intact replacement archive (or point them to an URL where they can download one).
The next thing you'll say is that Microsoft is a GPL-based entity because they provide GPL code in Services for Unix.
Hey, I didn't know that! Of course this means that Microsoft is bound to the GPLv2 terms (esp. the patent clause!). It also means that MS might be directly affected by GPLv3 in the future (of course that's not automatic; they could simply avoid any new versions of GPLed software and just maintain their own GPLv2 fork).
Why should I ever have to do that? Either I'm checking the correctness of operator+, then I'm interested in the implementation of it, and don't care at all about who might call it where for whatever reason. Or I'm checking the correctness of code which uses operator+, and then I already know where it is used (in the code I'm checking right now, and I don't care it it is called from anywhere else).
Indeed, with generic programming, the same code may call several different implementations of operator+, depending on what type it is used on. The same goes BTW for normal named functions. And the same is also true for virtual member functions (operator or not) in an OOP context.
I'd say if you have to find the callers of operator+ in order to check if it is implemented correctly, there's something fundamentally wrong with your code.
I hope you don't want to claim that it's considerably harder to find an implementation of operator+ than of a normally named function. Hint: The implementation always contains "operator" followed by "+".
If I saw v1 + v2, how would I know if it's adding the numerical vectors v1 and v2 or appending v2 to the end of v1 ? What if v1 and v2 are not numerical? Or do you think people should just intuitively know that for numerical vectors the + operator means element-wise addition and otherwise it means concatenation? If I saw addVector(v1, v2), how would I know it is mathematically adding the numerical vectors v1 and v2, or appending (adding) v2 to the end of v1? What if v1 and v2 are not numerical? Or do you think people should just intuitively know that for numerical vectors the addVector function means element-wise addition and otherwise it means concatenation?
You see, the argument doesn't in any way depend on whether you write the operation as an operator or as a function. That is, it's not really an argument against operators, it's an argument for consistency in naming (operators are nothing but special names with unusual function call syntax).
Slashdot Mirror
Your car is European. If it were American, it would get 20 per square millimeter instead.
Only? That's 3.48234 × 10^25 barn!
I don't see why the DRAM couldn't be integrated in the chip as well (except for the limited space on the chip, of course). One could even think of an integrated Flash drive. Of course you'll still need cables.
Please, give me the motherboard on an atom! That would really deserve the name "pico".
BTW, did anyone notice they omitted "micro"?
Even if MS could kill commercial Linux, it will not be able to kill Linux. Linux survived quite some time without business. Yes, development will slow down, but there will be no way it will be killed. That's the big advantage of FOSS: When IBM stopped supporting OS/2, it basically was dead. If IBM stops supporting Linux, then it will still exist and continue to be developed.
Well, on Slashdot it seems to generate some affect. However the effect will probably negligible.
As long as you are an end user (i.e. you neither modify nor redistribute the code), you are not affected by either license. You can use the code on your computer any way you like, no matter if it's GPLv2ed, GPLv3ed or BSDed. Add to that that most private end users don't care a shit anyway about licensing, and I don't see your lack of adoption.
Those affected by the GPLv2 vs. GPLv3 are those who develop software derived from other GPLed software, those who redistribute GPLed software (e.g. by selling CD-ROMs or by selling hardware with GPLed software installed), and those who want to GPL their software, but use certain non-GPLed libraries (because the GPLv3 is compatible to more of them).
Nobody is forced to use GPLv3 software. If your current GPLv2 software does everything you need, just continue using it. There's no termination (unless you violate GPLv2, of course). Of course should you want to have some of the features future GPLv3ed versions offer, then you'll have to decide if you change to the new GPLv3 version, or if you dislike the GPLv3 so much that you don't use that new version anyway. But it's your choice (you could even decide to make a GPLv2 fork by implementing those features yourself into the GPLv2 version).
Well, if you don't care what is done with your code, the BSD license is probably your best option. The advantage over public domain is that it explicitly disclaims any warranty (i.e. if someone tries your code and it doesn't work as expected and causes damage, they can't successfully sue you).
That's because GPL is not about the freedom for the initial developer (the copyright law already gives the initial developer all freedoms he ever needs; except that patents may undermine them, but there's nothing a license can change about that), the GPL is about the freedom of those who receive the code.
No, BSD is no copyleft. You can easily take BSD code and release it under a different, even proprietay license. You just have to keep the copyright claim intact (and the original BSD license also had that advertising clause). In short, as long as you are not lying about who wrote it, you may use and relicense it any way you want.
First note, that generally the most money is not made with private users, but with companies.
Now imagine your business e.g. depends vitally on Linux, but there happens to be a kernel bug which critically affects your business. If you just downloaded it from the net, you are on your own. Of course the developers will care about the bug, and eventually fix it, but if your business critically depends on it, an answer like "Next week I'll probably have time to look into that" will not be acceptable to you. You need the fix, and you need it as fast as possible. And that's what you pay for. You don't pay for the right to run it on your computers, you pay for the guarantee that if something goes wrong, there's someone who cares about that, and whom you can blame if it doesn't work out as expected (don't underestimate the importance of the latter point!).
Ok, but if you write the code, anyone can step in and offer service for it, right? Right. But the author of the code has an invaluable advantage: No one would doubt that he knows the code better than anyone else. So if something goes wrong, whom would you trust more to be able to fix it, the original author or some random other person? Well, if it's not the author, you'd probably better stay away from the code at all.
You'll probably want to restrict this warranty a bit further. After all, can you say for sure that your compiler doesn't have a bug, which causes the executable to misbehave in certain uncommon situations, despite the source being correct?
The usual warranty I see on software products is that the disk works at least for some (usually quite short) time. So maybe you should simply provide the warranty that the archives can be unpacked, provided it is attempted on a working computer with appropriate, working unpacking software, and there's still enough disk space free on the destination drive.
If someone complains because he got a corrupted archive, then you simply can mail them an intact replacement archive (or point them to an URL where they can download one).
Hey, I didn't know that! Of course this means that Microsoft is bound to the GPLv2 terms (esp. the patent clause!). It also means that MS might be directly affected by GPLv3 in the future (of course that's not automatic; they could simply avoid any new versions of GPLed software and just maintain their own GPLv2 fork).
You link is broken. The following should work:r ussels-rms-transcript.en.html
http://www.germany.fsfeurope.org/projects/gplv3/b
I don't need frinking lasers. My Ballmerbot easily beats every Chairbot by just throwing it through the room!
Why should I ever have to do that? Either I'm checking the correctness of operator+, then I'm interested in the implementation of it, and don't care at all about who might call it where for whatever reason. Or I'm checking the correctness of code which uses operator+, and then I already know where it is used (in the code I'm checking right now, and I don't care it it is called from anywhere else).
Indeed, with generic programming, the same code may call several different implementations of operator+, depending on what type it is used on. The same goes BTW for normal named functions. And the same is also true for virtual member functions (operator or not) in an OOP context.
I'd say if you have to find the callers of operator+ in order to check if it is implemented correctly, there's something fundamentally wrong with your code.
Yes, I chose those codes on purpose. Do you know what they mean, as the first two bytes of a wintel executable?
Yes. But did you check to which posting I actually answered? Hint: It was not yours.You want to look up the characters corresponding to the ASCII codes 77 and 90 :-)
AFAIK gcc uses its own homegrown GC (which heavily relies on annotations in the source). The Boehm GC is however used for gcj.
I hope you don't want to claim that it's considerably harder to find an implementation of operator+ than of a normally named function. Hint: The implementation always contains "operator" followed by "+".
Don't forget the Apple Computer/Apple Records problem ...
Well, here's the code NVidia tries to hide. You don't have it from me, OK?
Because the software has already been written? From the summary: "It's a legacy app"
You see, the argument doesn't in any way depend on whether you write the operation as an operator or as a function. That is, it's not really an argument against operators, it's an argument for consistency in naming (operators are nothing but special names with unusual function call syntax).