What his joke is offering is the insight that every easy route (and most moderately complex routes) to blocking spam has already been tried and failed.
And that is completely beside the point.
The fight against spam is an arms race, as the form points out. The form gets trotted out every time the Side of Niceness gets a new weapon. Yes, it's good to keep perspective: while there's money in spam, there will be spam. And in the absence of herd immunity, there will be a lot of spam. But it's not true that any new tool is useless.
Personally, I'd love to see a system to make SPF actually work, even when people don't opt in. It wouldn't help as much as the author of the paper seems to think, but it would help.
In the visual effects business, Blinn's Law is the counterpoint to Moore's Law. It states that the amount of time it takes to compute a frame of film remains constant over time, because audience expectation increases at the same speed as computer hardware.
It is, however, wrong. Audiences just want to see a good movie. It's studio expectation increases over time.
No audience member ever boycotted a movie because it didn't have enough eye candy in it. (In the upcoming Tintin movie, the CGI characters have skin pores. Can you imagine it? "Yeah, well, I was going to see that movie, but then I heard that the other one has skin pores! Let's see that instead!")
I imagine games are much the same. Blinn's Law is actually Parkinson's Law in disguise.
Source does you no good if nobody "out there" is using the software. That's where money comes in.
To make great software, you only need source. If you want leverage (e.g. for everyone to support open standards), you need brainshare and money. And money buys brainshare.
Putting a BSDL-ed code under a MORE RESTRICTIVE license is RELICENSING, which you have no right for, (unless you own copyright in the BSDL-ed code or have consent of such owners).
Of course. And that's the situation that Theo is complaining about, but it's not the situation in this hypothetical.
If you put BSDL'd code in a GPL'd application, the BSDL'd code is still BSDL'd, but the work as a whole is GPL'd, and that's okay.
And if you make modifications sufficient to qualify for copyright, and you licence those modifications under the GPL, the original BSDL'd code is still BSDL'd and everything is legal (though Theo correctly points out that this is extremely rude).
I'm sorry, but C is just a poor choice for ensuring correctness.
True enough, but Unix is essentially a C virtual machine. And it has to do enough low-level hackery that regardless of what language you wrote it in, it would resemble C.
Something that's not widely appreciated is that any sufficiently large system is written in layers, with "hard" layers underneath (e.g. the low-level-C combined with template-hackery that you often see in C++ libraries, or the run-time systems that you see in higher-level languages, again often written in C) with "softer" layers on top.
In Unix, the kernel is the "hard" layer, and user space is the "soft" layer.
First of all, open up your copy of the C standard (any of them will do) and grep for the phrase "undefined behaviour".
And after you've done that, look up the Unix 98 standard and do the same.
The problem with program verification in the case of Unix is that the specification is often harder to debug than the program. Imagine that you have 15 possible generations of the same chip to interface with, each of which has slight quirks, but two of them have outright bugs that need to be worked around. Did you see what needed to be done to protect against the F00F bug? Try expressing that in Z.
OK, now that I've gotten that off my chest, the real problem here is that Unix is too complicated. It is possible to break it up into manageable pieces (see QNX, for example), but BSD ain't it.
I live in the Netherlands, and if I look out of the window, I'd not immediately come up with the idea that the earth is round.
Like the Round Earth Theory, or the fact that counting begins at zero, evolution is obvious in retrospect.
When the round earth was discovered 2500 odd years ago, it was so obvious that pretty much every educated person at the time and since agreed with it. The same is true of evolution, except that it took 2350 more years to discover it.
You can, but only if you own copyright in the BSDL-ed code or have consent of such owners.
Even if you don't have consent, you can.
The key thing here (and this was the problem with the "old" BSD licence) is that the BSDL doesn't require anything that the GPL doesn't. So the GPL is merely an additional set of restrictions on top of the BSDL. The GPL has a problem with additional restrictions, but the BSDL doesn't. And since the BSDL contains no additional restrictions that aren't in the GPL (apart from the requirement to keep the BSD licence notice intact in the source code, which the GPL doesn't have a problem with).
The GPL explicitly and expressly *REQUIRES* that ALL portions of a program distributed under the GPL are under the GPL.
I interpreted that as meaning, for example, that you couldn't take BSD licensed code and use it in the Linux kernel. Which, of course, you can do. And the GPL also explicitly says that if you subsequently take that part out, the GPL doesn't apply to it.
Change of formatting (e.g. changing tabs to spaces, re-indenting).
s/unsigned int/uint32/
Adding a comment or two.
Adding glue code. The glue code is a derivative work, but the original code is essentially untouched.
Things that are likely to be substantial:
A rewrite or restructure.
Adding comments that are substantial enough to count as "commentary".
Adding a feature/enhancement.
As always, YMMV. Remember that the law is not Boolean, and cases are decided by weighing competing probabilities. If in doubt, either release your modifications under the original licence, or make it clear that it's only your modifications that are licensed under the new terms.
The GPL explicitly and expressly *REQUIRES* that ALL portions of a program distributed under the GPL are under the GPL.
And where did you read that in the GPL?
What the GPL actually "explicitly and expressly requires" is that the work as a whole be distributed under the GPL.
In fact, the GPL explicitly denies your reading of it. From GPL2, section 2:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Precisely. And if you received source code under a dual BSD/GPL licence, you have to redistribute it under the same terms. Removing the BSD licence is removing a freedom (the freedom to pick the other licence), and that violates the GPL as well as the BSD licence.
You jest, but there are currently 243 fields in the MARC21 standard, and the list isn't getting shorter. And I haven't counted how many use attributes are in Z39.50 Bib-1, but it must be pretty close to that.
The moral of this story is that the "something wrong" that you may be doing is using a RDBMS for something that it's not good at.
The Fundamental Theorem of Calculus is that the area under a function between two points is the difference of the antiderivative evaluated at those points.
That's a common misconception. There is no "the" antiderivative of an integrable function. In general, there are many. The Second Fundamental Theorem of Calculus only applies to the continuous antiderivatives.
To see why, consider the function f(x)=(x^4-3x^2+6)/(x^6-5x^4+5x^2+4), and try to compute the definite integral from x=1 to x=2.
g(x)=Arctan((x^3-3x)/(x^2-2)) is an indefinite antiderivative (try taking the derivative if you don't believe me), but it gives the wrong answer because it is discontinuous at x=sqrt(2).
On the other hand, g(x)=Arctan((x^5-3x^3+x)/2)+Arctan(x^3)+Arctan(x) is another indefinite antiderivative, which gives the correct answer.
Geeks, as far as I can tell, believe most strongly in a meritocracy. This is why they have no problem falling behind benevolent dictators like Linus or Theo.
Taking this to government politics, a perceived (actual?) lack of merit means that most do not fall behind the two major parties that you find in most English-speaking democracies. Assuming actual intelligence (e.g. never going to vote for a single-issue party), that leaves two places to go: progressive or libertarian.
Which one you pick depends on two factors. One is who you perceive to be to blame for everything. If you blame governments (or read too much Heinlein), you tend to go libertarian. If you blame corporations (or read too much cyberpunk), you tend to go progressive.
The other is that some geeks never outgrew their Ayn Rand phase.
Slashdot Mirror
Woah. I mean woah, dude.
And that is completely beside the point.
The fight against spam is an arms race, as the form points out. The form gets trotted out every time the Side of Niceness gets a new weapon. Yes, it's good to keep perspective: while there's money in spam, there will be spam. And in the absence of herd immunity, there will be a lot of spam. But it's not true that any new tool is useless.
Personally, I'd love to see a system to make SPF actually work, even when people don't opt in. It wouldn't help as much as the author of the paper seems to think, but it would help.
I dare you to repeat that next time you get hit with a nuisance lawsuit. It costs you money, time and stress.
If he had to pay costs every time he loses one of these, I wouldn't worry so much.
In the visual effects business, Blinn's Law is the counterpoint to Moore's Law. It states that the amount of time it takes to compute a frame of film remains constant over time, because audience expectation increases at the same speed as computer hardware.
It is, however, wrong. Audiences just want to see a good movie. It's studio expectation increases over time.
No audience member ever boycotted a movie because it didn't have enough eye candy in it. (In the upcoming Tintin movie, the CGI characters have skin pores. Can you imagine it? "Yeah, well, I was going to see that movie, but then I heard that the other one has skin pores! Let's see that instead!")
I imagine games are much the same. Blinn's Law is actually Parkinson's Law in disguise.
I was with you right up to the misuse of "begs [...] the question".
Source does you no good if nobody "out there" is using the software. That's where money comes in.
To make great software, you only need source. If you want leverage (e.g. for everyone to support open standards), you need brainshare and money. And money buys brainshare.
Of course. And that's the situation that Theo is complaining about, but it's not the situation in this hypothetical.
If you put BSDL'd code in a GPL'd application, the BSDL'd code is still BSDL'd, but the work as a whole is GPL'd, and that's okay.
And if you make modifications sufficient to qualify for copyright, and you licence those modifications under the GPL, the original BSDL'd code is still BSDL'd and everything is legal (though Theo correctly points out that this is extremely rude).
True enough, but Unix is essentially a C virtual machine. And it has to do enough low-level hackery that regardless of what language you wrote it in, it would resemble C.
Something that's not widely appreciated is that any sufficiently large system is written in layers, with "hard" layers underneath (e.g. the low-level-C combined with template-hackery that you often see in C++ libraries, or the run-time systems that you see in higher-level languages, again often written in C) with "softer" layers on top.
In Unix, the kernel is the "hard" layer, and user space is the "soft" layer.
And after you've done that, look up the Unix 98 standard and do the same.
The problem with program verification in the case of Unix is that the specification is often harder to debug than the program. Imagine that you have 15 possible generations of the same chip to interface with, each of which has slight quirks, but two of them have outright bugs that need to be worked around. Did you see what needed to be done to protect against the F00F bug? Try expressing that in Z.
OK, now that I've gotten that off my chest, the real problem here is that Unix is too complicated. It is possible to break it up into manageable pieces (see QNX, for example), but BSD ain't it.
Like the Round Earth Theory, or the fact that counting begins at zero, evolution is obvious in retrospect.
When the round earth was discovered 2500 odd years ago, it was so obvious that pretty much every educated person at the time and since agreed with it. The same is true of evolution, except that it took 2350 more years to discover it.
Even if you don't have consent, you can.
The key thing here (and this was the problem with the "old" BSD licence) is that the BSDL doesn't require anything that the GPL doesn't. So the GPL is merely an additional set of restrictions on top of the BSDL. The GPL has a problem with additional restrictions, but the BSDL doesn't. And since the BSDL contains no additional restrictions that aren't in the GPL (apart from the requirement to keep the BSD licence notice intact in the source code, which the GPL doesn't have a problem with).
What you wrote was:
I interpreted that as meaning, for example, that you couldn't take BSD licensed code and use it in the Linux kernel. Which, of course, you can do. And the GPL also explicitly says that if you subsequently take that part out, the GPL doesn't apply to it.
Again, I'm not a lawyer, but here's my take.
Things that are probably not substantial:
Things that are likely to be substantial:
As always, YMMV. Remember that the law is not Boolean, and cases are decided by weighing competing probabilities. If in doubt, either release your modifications under the original licence, or make it clear that it's only your modifications that are licensed under the new terms.
And where did you read that in the GPL?
What the GPL actually "explicitly and expressly requires" is that the work as a whole be distributed under the GPL.
In fact, the GPL explicitly denies your reading of it. From GPL2, section 2:
Precisely. And if you received source code under a dual BSD/GPL licence, you have to redistribute it under the same terms. Removing the BSD licence is removing a freedom (the freedom to pick the other licence), and that violates the GPL as well as the BSD licence.
You jest, but there are currently 243 fields in the MARC21 standard, and the list isn't getting shorter. And I haven't counted how many use attributes are in Z39.50 Bib-1, but it must be pretty close to that.
The moral of this story is that the "something wrong" that you may be doing is using a RDBMS for something that it's not good at.
If it's any consolation, I can't believe I got a +1 Insightful for something so off-topic.
That's a common misconception. There is no "the" antiderivative of an integrable function. In general, there are many. The Second Fundamental Theorem of Calculus only applies to the continuous antiderivatives.
To see why, consider the function f(x)=(x^4-3x^2+6)/(x^6-5x^4+5x^2+4), and try to compute the definite integral from x=1 to x=2.
g(x)=Arctan((x^3-3x)/(x^2-2)) is an indefinite antiderivative (try taking the derivative if you don't believe me), but it gives the wrong answer because it is discontinuous at x=sqrt(2).
On the other hand, g(x)=Arctan((x^5-3x^3+x)/2)+Arctan(x^3)+Arctan(x) is another indefinite antiderivative, which gives the correct answer.
It's been done, and it's called "minarchism". It's related to anarchism.
Generally speaking, though, there is such a thing as a progressive libertarian. You probably know them better as civil libertarians.
Geeks, as far as I can tell, believe most strongly in a meritocracy. This is why they have no problem falling behind benevolent dictators like Linus or Theo.
Taking this to government politics, a perceived (actual?) lack of merit means that most do not fall behind the two major parties that you find in most English-speaking democracies. Assuming actual intelligence (e.g. never going to vote for a single-issue party), that leaves two places to go: progressive or libertarian.
Which one you pick depends on two factors. One is who you perceive to be to blame for everything. If you blame governments (or read too much Heinlein), you tend to go libertarian. If you blame corporations (or read too much cyberpunk), you tend to go progressive.
The other is that some geeks never outgrew their Ayn Rand phase.
Give me a week and a modern microcontroller and I'll build you one. Someone else can write the driver.
I see we're on the same wavelength! Shall I calendar lunch?
I'm pleased the concept resonated with you.
You've clearly got no idea how to be a manager. Let me translate that for you...
Be people-smart with a view to enhancing workplace synergy.
Respect the value of human capital. Gift a space for discussants to talk through their concerns and add value to the dialogue.
Work smarter, and keep on top of your key performance indicators.
Prepare for, and manage, corporate disconnects.
There, now you're ready to be a manager!
As Dave Letterman quipped many, many years ago: The drivers would not stand for it and voted to blockade City Hall. Except nobody knew where it was.
That ruined the joke for me. Like Stroustrup would ever include the legacy non-namespaced header!