I'm no expert on Fitts' law (I only just heard about it from the guy I was responding to earlier), but the two key parameters are the distance from the starting point to the center of the destination object and the width of the destination object in the direction of motion. In particular, the important number is their *ratio*. This makes sense -- the farther away an object is, the longer it takes to get there, and the larger an object is, the less time you have to spend making precision adjustments.
So the question becomes, "What do you do in the edge case of a border object?" (pun intended) My solution is that the ratio converges to 1 for the average case because (as I said earlier), thinking of the width as "infinite" is actually incorrect. Rather, no matter how far the pointer was "slung" past the edge, the time taken to sling it is equal to the amount of time it would have taken to reach an object as wide as the distance slung.
My answer to mojoNYC above mostly addresses your objections, but you're wrong about one thing.
it's a perceived finite, and a practical infinite, as the target has a fixed size on the screen
It doesn't matter how large the size is on the screen. All that matters is the "size" of the hotspot, where "size" means the difference between the minimum and maximum movements which allow the pointer to touch it.
Fitts' law is evaluates the *mechanics* of motion. That's why all the people talking about how it shows that edge-menus are "easier" are all wrong. Fitts' law says nothing about ease-of-use. It only evaluates the time it takes to flick your wrist.
I didn't bother with a two-dimensional analysis because I didn't think it was useful. The horizontal axis for edge-menus and app-menus are nearly identical.
Umm... I think you have me confused with someone else. I entered the discussion late, and I haven't commented on OS X at all.
Zeno's "paradox" is not applicable. First because we have tools to deal with limits of infinite ratios, and second because there really isn't anything infinite in the case of edge-menus. Calling it so is a mathematical misnomer.
I didn't disagree with Fitts' law at all. Quite the contrary, I took it as given and/used/ it to draw my conclusions. My evaluation even supported your position that edge-menus are currently and have in the past been a usability boon.
It doesn't appear that you read my post very carefully. Perhaps you should peruse it again.
I already took that into account. That's why my Fitts' law evaluation of edge-menus gave them a D/W ratio of 1. Otherwise it would have been 1/(2w), where w is the width of the menu; in my case where menus are 1/40 of screen size, the ratio would have been 20 on average.
[T]argets at the edge of a display are infinitely large (given that you can overshoot them endlessly without missing them)
They are NOT "infinitely large". If they were infinitely large, then you wouldn't have to move the mouse *at all* to click on them. Calling them "infinitely large" just confuses people who know what the words "infinite" and "large" mean.
He's referring to Fitt's Law, and one of its interesting corollaries. The relevant bit of the law is that the time it takes to point at a target is related to the size of that target.
Fitts' law, according to that Wikipedia article, states that the time it takes to complete a movement is proportional to the binary logarithm of the ratio between the distance to the center of the target and the width of the target in the direction of motion.
Note that Fitts' law does not say anything about how "easy" the task is -- just how much time it takes.
Now, the argument you and others seem to be making is that, for the purposes of Fitts' law, an object at the edge of the mousing area can be considered to have infinite width; the amount of time it takes to complete the action is therefore minimized.
However, you are neglecting the other parameter: if the width of the target is infinite, then the distance to its center is also infinite, and the ratio between the two converges to 1/2. But it's still not even that good: the 1/2 ratio between the "center" and the width doesn't hold in this case. Rather than being infinite, the width of the edge in a given instance is however much farther past the edge of the screen the user chooses to travel. The "center" is therefore effectively wherever the user clicks, and the ratio between the width and the center converges to 1 (it converges more quickly for narrower hotspots, so a menu bar would have a ratio very nearly 1). So Fitts' law gives T = a + (.58)b.
On my monitor, each application takes up roughly 1/4 of the screen, so while performing a sequence of actions, the menu bar is, on average, only 1/8 of a monitor width away from the location of the next action. The menu bar is 1/40 screen tall, so my average D/W ratio 5. So by Fitts' law, that gives T = a + (2.58)b.
So the log-factor ratio is 4.4, in favor of edge menus.
What this neglects is the time it then takes to perfor your NEXT action. On small monitors, the distance from the edge to any other point on the screen is small, so the cost of moving back to the location of interest isn't prohibitively large. With large monitors, however, the edge advantage actually becomes an edge disadvantage, as you have to move farther back.
For edge menus, the average distance is half the monitor size, so Fitts' law says the time is proportional to lg (1/(2w) + 1). For my screen, with the menu bar at the top of the app, the average distance is only 1/8 of the screen. So it's proportional to lg(1/(8w) + 1).
The ratio between the two is -1.415 - lg w. (Where the units for w are in terms of the size of the screen). So to click on a large item, edge menus still have the advantage. But for me, most things are button-sized (again, 1/40 the screen size in the vertical direction). In that case, the ratio comes out to about 3.9 in favor of app-menus. The ratio will favor app-menus more as the size of the target becomes smaller and less as the size becomes larger.
So not only does Fitts' law show that users with my usage pattern (roughly, as monitor size increases, window sizes remain contstant), there is no clear winner between app-menus and edge menus. But app-windows are getting more advantageous as monitor sizes increase, while edge-menus are becoming less advantageous.
If someone sees a fault in my math or reasoning, please point it out to me.
Which means that if no hardware replacement exists which could run the software, you in practice would not be able to run the software "for any purpose".
You built the software. Why isn't it then your responsibility to build the hardware on which you wish to run it? Why is it someone else's responsibility to provide you with hardware on which to run your MODIFIED software?
Freedom zero is a myth, and I'm sick of hearing about it. It doesn't exist, and it never has! Any piece of hardware has limitations which make it impossible to achieve in practice. Ever.
The simple user, which is the one the GPL is focused on
GPL has never been focused on the simple user. The simple user does not modify programs and thus has no use for source code.
So yes, the GPL already always _meant_ that you should have the rights to run software on the same device the manufacturer runs it on if he uses GPL
No, it didn't. If it had, Stallman wouldn't have needed to change the license to accomplish that. QED.
>> The GPLv3 aims to control the distribution of hardware. >No it doesnt, so stop lying.... It stops greedy fucks from using... DRM measures [to keep you from running it].
You call me a liar and then repeat what I said in the same breath.
The fact is that GPLv2 and GPLv3 are fundamentally different licenses with different repurcussions. RMS may have *meant* some of the things in GPLv3 when he wrote v2, but they aren't there, and a hell of a lot of people never wanted them.
In the specific case of GPLv3, what was corrected was the hole that allowed a distributor to work its way around the "for any purpose" sentence in freedom 0. A DRM'ed hardware, the means chosen by the distributor do distribute the software, only allows the end user to use that software for certain purposes.
That is false. "Tivoization" (what a horrible word) still allows you to run your (modified) software for any purpose you wish. It just prevents you from using the original hardware to do so. Call a spade "a spade": The GPLv3 aims to control the distribution of hardware.
Would you say the 13th amendment made us more or less free? The GPL is exactly analogous.
No, it isn't. The 13th Amendement (which abolished slavery in the US, for those of you following along) had the net effect of making "us" more free because it dealt with the interaction between *people*. The GPL deals with the interaction between a person and *software*. Contrary to the neoligsm, a piece of software (AIs notwithstanding) cannot have freedom; only people can.
So while I mostly agree with your sentiment (that even if you take away some aspect of freedom, the net effect can be an overall increase of freedom), I disagree that the method that the 13th Amendment took to deal with the issue of slavery is "exactly analogous" to the copyleft approach to the issue of copyright because the issues themselves are not analogous.
It has nothing to do with the setting of the story. Being a fantasy doesn't excuse deus ex. Let me add some emphasis: "... the author uses a mechanism hidden from the audience (until it happens) to make something happen that shouldn't be possible (within the setting of the book)".
"Shouldn't be possible" perhaps isn't the best phrasing either. You could argue that anything the author makes happen,/should/ happen. But that's not what I mean; it's whether its happening is consistent with prior events. It doesn't even have to seem impossible; an "off-camera" character showing up just in the nick of time to save the day, with no real explanation how and why they got there just so, is a deus ex, for example.
A fantasy novel can have internal consistency. If it doesn't, its being a fantasy is not a valid excuse.
I originally switched to Linux years ago because I had a piece of hardware that I used on a daily basis (TV tuner card) which Windows driver was incredibly buggy. Also, the Linux driver for my on-board RAID controller was much better than the Windows one.
One of my hobbies is making interesting software environments which boot from removable media or the network. While some Windows tools exist which can facilitate this, some powerful nix-only concepts like mount -o loop just don't have Windows analogs.
My favorite video player and encoder are mplayer and mencoder. While they are available for Windows, they run about twice as fast on Linux as it does on Windows (I managed to do a custom Win32 build, so it really is an apples-to-apples comparison) and some DVDs which rip fine on Linux don't work on Windows.
Scripting batch processes like image processing on my photo albums or encoding portions of my FLAC audio collection to something smaller for my portable music player is much simpler. Sure, there are a few apps that have preset functionality for something close to what I want, but nothing is ever *just right*. And while Windows does have an amazing scriptability thanks to WSH and WMI, it is much more cumbersome than shell scripts (and cmd.exe is a horrible experience to script in) and most non-MS desktop apps don't provide COM interfaces. I know what you're thinking -- most desktop users don't write scripts. True, but most desktop users would be happy to USE scripts that other people write.
Other than that, I'd be pretty happy with Windows+Cygwin.
Your only right to use their network is under contract with them. Break the contract, and your use of their network constitutes computer tresspassing.
Re:New Update since i submited this yesterday
on
TimeWarner DNS Hijacking
·
· Score: 2, Informative
Can they even demonstrate that I don't know of the existance of that malware? Maybe I installed it myself, maybe I'm monitoring it.
Then you violated your TOS and were on their network illegally.
It's your PC, but it's THEIR network. They have the right to defend their network and the obligation to protect other people using it. I'd even bet their TOS authorizes this kind of behavior.
I half-agree with you. They're lazy ways to get out of tricky plot points, and they therefore drag a book down.
You're right that the term "deus ex machina" comes from old great plays. But back then, it was just the machine that let characters "fly" (by attaching the actors to wires and lifting them up). That's it! The term as applied to plots is completely derogatory: the author uses a mechanism hidden from the audience to make something happen that shouldn't be possible. It's pretty much the worst thing you can say about a plot.
He was refering to the themes and morals, not to the mechanics or plotpoints. Obviously, the world being created and guided by a paganesque pantheon wouldn't mesh well with Catholicism. If you see a clash between Islam and Chritianity (or the Middle-east and Europe or whatever) when you read Tolkien, that says a lot more about you than it does about Tolkien.
Not if you follow the FSFs suggestion that every contributers transfers the ownership of the code to the original copyright holder.
That's an example of "asking for special permission." Also, the FSF doesn't suggest that contributers transfer ownership to the original copyright holder; they ask that everyone transfer ownership *to the FSF*.
If it is a simple security hole then while you couldn't take the patch
That's what I said.... you could look at it and write your own version.
You can, but that's legally dangerous. The problem is that what you consider obvious might not be so obvious to a judge or jury. Once you look at someone else's solution to a problem, the burden is on you to prove that your solution was developed completely independently. That's the purpose of clean-room reverse engineering, to avoid that particular legal pit.
It's much safer to just ask for a description of the problem and create a solution without looking at a GPLed patch.
Saying otherwise would be much the same as SCO saying that Linux stole a line of code from Unix that says for(i=0;i
Hyperbole is unbecoming. You cannot copyright a single line of code.
If it's just a buffer overrun caused by an improper bounds check, then you're fine. But if it's a design or algorithmic error, you have to be careful. The problem is that you don't know until/after/ you look at the code. It's much safer just not to look.
What if I were to take another GPL software like Inkscape and add a billing module, could I close source the module?
That's a complicated quetion and there's no general-purpose answer. The problem is the legal interpretation of "derivative work". If the module is "derived" (in a legal sense as applied to software) from the Inkscape source, then no. If your module really is independent, then yes.
Take nVidia's closed-source Linux drivers, for example. They're basically a plug-in for the kernel. Some people think that because they rely on kernel internals, they are "derived" and should have to be GPL. Others think that because they're a module, they're not derived and so proprietary is OK.
Someone else taking my code then selling it, with or without bug fixes and such, without me seeing any money.
They can do that under most Free Software licenses, including GPL and BSD. But why would anyone buy it from them if they can get it from you for free? The only sensible reason would be if they had improved it somehow. If the original program were BSD, this new-and-improved version could be distributed closed-source. If the original program were GPL, the new-and-improved version would/have/ to be GPL too (and they could still sell it -- but they couldn't stop anyone they sold it to from giving it away for free).
>If you really wants to be able to sell (software including) his code, >you can ask him for special permission to do so.
You don't need "Joe's" permission to sale software with his code do you?
I spoke sloppily. In the example, the software "you" were selling was the closed-source version. I meant that you couldn't include it in the closed-source software without his permission. You could sell it without his permission, but you would have to use the GPL to cover the whole piece of software (so anyone you sold it to could give it away for free).
That's what some people mean when they call the GPL "viral". If you include a little bit of GPL code in a large piece of software, you can't just say that it's 98% closed and 2% open. It's either all-GPL or no-GPL.
Your impression of the effects of the licenses is misguided.
Say you develop a photo-editing (or whatever) piece of software and release it under the GPL. Then you add a few new features and decide to start charging money for a closed-source version with more functionality. No problem! That is just fine.
Now consider that Joe fixes a security hole in the GPL version of your software, and the same hole exists in your closed version. You can use his patch to fix the GPL version, but you cannot use it to fix the closed version.
You see the difference? If it's your code, the GPL doesn't keep you from doing anything you want. The only thing it restricts is what you can do with Joe's code. Joe was nice enough to give you his code for free; why should you be allowed to charge other people for it?
Or, from Joe's perspective, the GPL limits what you can do with Joe's code. If you really wants to be able to sell (software including) his code, you can ask him for special permission to do so. If the code he sent you really was all his (he owns the copyright; he didn't copy it from some other GPL source), Joe could give (or sell) you permission to include the code in your closed-source software. Now that sounds fair to me.
By all means, continue disliking the GPL (I certainly don't particularly like it). But please do so for the right reasons.
Actually, he used the term correctly. You are using it incorrectly (and so does Intel -- but they, unlike you, have a good reason). In the original 8086, a word was in fact 16 bits. As the x86 architecture expanded to a 32-bit architecture, the word size became 32 bits. To maintain backwards compatibility with documentation and compilers/assemblers, they just started calling those words "double words" (this avoided a LOT of confusion and pointless waste of effort that would have occured had they insisted on pedantry). On ia32, a "dword" is the word size of the system. When amd64 came out, AMD did the same thing for the same reasons.
The number of open ports is a poor metric. Windows multiplexes ports 135-139 and 445 such that just about everything goes through them. This just exacerbates the problem because you can't use a firewall to protect yourself.
Slashdot Mirror
I'm no expert on Fitts' law (I only just heard about it from the guy I was responding to earlier), but the two key parameters are the distance from the starting point to the center of the destination object and the width of the destination object in the direction of motion. In particular, the important number is their *ratio*. This makes sense -- the farther away an object is, the longer it takes to get there, and the larger an object is, the less time you have to spend making precision adjustments.
So the question becomes, "What do you do in the edge case of a border object?" (pun intended) My solution is that the ratio converges to 1 for the average case because (as I said earlier), thinking of the width as "infinite" is actually incorrect. Rather, no matter how far the pointer was "slung" past the edge, the time taken to sling it is equal to the amount of time it would have taken to reach an object as wide as the distance slung.
My answer to mojoNYC above mostly addresses your objections, but you're wrong about one thing.
it's a perceived finite, and a practical infinite, as the target has a fixed size on the screen
It doesn't matter how large the size is on the screen. All that matters is the "size" of the hotspot, where "size" means the difference between the minimum and maximum movements which allow the pointer to touch it.
Fitts' law is evaluates the *mechanics* of motion. That's why all the people talking about how it shows that edge-menus are "easier" are all wrong. Fitts' law says nothing about ease-of-use. It only evaluates the time it takes to flick your wrist.
I didn't bother with a two-dimensional analysis because I didn't think it was useful. The horizontal axis for edge-menus and app-menus are nearly identical.
Umm... I think you have me confused with someone else. I entered the discussion late, and I haven't commented on OS X at all.
/used/ it to draw my conclusions. My evaluation even supported your position that edge-menus are currently and have in the past been a usability boon.
Zeno's "paradox" is not applicable. First because we have tools to deal with limits of infinite ratios, and second because there really isn't anything infinite in the case of edge-menus. Calling it so is a mathematical misnomer.
I didn't disagree with Fitts' law at all. Quite the contrary, I took it as given and
It doesn't appear that you read my post very carefully. Perhaps you should peruse it again.
I already took that into account. That's why my Fitts' law evaluation of edge-menus gave them a D/W ratio of 1. Otherwise it would have been 1/(2w), where w is the width of the menu; in my case where menus are 1/40 of screen size, the ratio would have been 20 on average.
[T]argets at the edge of a display are infinitely large (given that you can overshoot them endlessly without missing them)
They are NOT "infinitely large". If they were infinitely large, then you wouldn't have to move the mouse *at all* to click on them. Calling them "infinitely large" just confuses people who know what the words "infinite" and "large" mean.
He's referring to Fitt's Law, and one of its interesting corollaries. The relevant bit of the law is that the time it takes to point at a target is related to the size of that target.
Fitts' law, according to that Wikipedia article, states that the time it takes to complete a movement is proportional to the binary logarithm of the ratio between the distance to the center of the target and the width of the target in the direction of motion.
Note that Fitts' law does not say anything about how "easy" the task is -- just how much time it takes.
Now, the argument you and others seem to be making is that, for the purposes of Fitts' law, an object at the edge of the mousing area can be considered to have infinite width; the amount of time it takes to complete the action is therefore minimized.
However, you are neglecting the other parameter: if the width of the target is infinite, then the distance to its center is also infinite, and the ratio between the two converges to 1/2. But it's still not even that good: the 1/2 ratio between the "center" and the width doesn't hold in this case. Rather than being infinite, the width of the edge in a given instance is however much farther past the edge of the screen the user chooses to travel. The "center" is therefore effectively wherever the user clicks, and the ratio between the width and the center converges to 1 (it converges more quickly for narrower hotspots, so a menu bar would have a ratio very nearly 1). So Fitts' law gives T = a + (.58)b.
On my monitor, each application takes up roughly 1/4 of the screen, so while performing a sequence of actions, the menu bar is, on average, only 1/8 of a monitor width away from the location of the next action. The menu bar is 1/40 screen tall, so my average D/W ratio 5. So by Fitts' law, that gives T = a + (2.58)b.
So the log-factor ratio is 4.4, in favor of edge menus.
What this neglects is the time it then takes to perfor your NEXT action. On small monitors, the distance from the edge to any other point on the screen is small, so the cost of moving back to the location of interest isn't prohibitively large. With large monitors, however, the edge advantage actually becomes an edge disadvantage, as you have to move farther back.
For edge menus, the average distance is half the monitor size, so Fitts' law says the time is proportional to lg (1/(2w) + 1). For my screen, with the menu bar at the top of the app, the average distance is only 1/8 of the screen. So it's proportional to lg(1/(8w) + 1).
The ratio between the two is -1.415 - lg w. (Where the units for w are in terms of the size of the screen). So to click on a large item, edge menus still have the advantage. But for me, most things are button-sized (again, 1/40 the screen size in the vertical direction). In that case, the ratio comes out to about 3.9 in favor of app-menus. The ratio will favor app-menus more as the size of the target becomes smaller and less as the size becomes larger.
So not only does Fitts' law show that users with my usage pattern (roughly, as monitor size increases, window sizes remain contstant), there is no clear winner between app-menus and edge menus. But app-windows are getting more advantageous as monitor sizes increase, while edge-menus are becoming less advantageous.
If someone sees a fault in my math or reasoning, please point it out to me.
Which means that if no hardware replacement exists which could run the software, you in practice would not be able to run the software "for any purpose".
... It stops greedy fucks from using ... DRM measures [to keep you from running it].
You built the software. Why isn't it then your responsibility to build the hardware on which you wish to run it? Why is it someone else's responsibility to provide you with hardware on which to run your MODIFIED software?
Freedom zero is a myth, and I'm sick of hearing about it. It doesn't exist, and it never has! Any piece of hardware has limitations which make it impossible to achieve in practice. Ever.
The simple user, which is the one the GPL is focused on
GPL has never been focused on the simple user. The simple user does not modify programs and thus has no use for source code.
So yes, the GPL already always _meant_ that you should have the rights to run software on the same device the manufacturer runs it on if he uses GPL
No, it didn't. If it had, Stallman wouldn't have needed to change the license to accomplish that. QED.
>> The GPLv3 aims to control the distribution of hardware.
>No it doesnt, so stop lying.
You call me a liar and then repeat what I said in the same breath.
The fact is that GPLv2 and GPLv3 are fundamentally different licenses with different repurcussions. RMS may have *meant* some of the things in GPLv3 when he wrote v2, but they aren't there, and a hell of a lot of people never wanted them.
I'll remember not to install close-source 3D-acceleration drivers on my servers. Thanks for the hint.
In the specific case of GPLv3, what was corrected was the hole that allowed a distributor to work its way around the "for any purpose" sentence in freedom 0. A DRM'ed hardware, the means chosen by the distributor do distribute the software, only allows the end user to use that software for certain purposes.
That is false. "Tivoization" (what a horrible word) still allows you to run your (modified) software for any purpose you wish. It just prevents you from using the original hardware to do so. Call a spade "a spade": The GPLv3 aims to control the distribution of hardware.
Would you say the 13th amendment made us more or less free? The GPL is exactly analogous.
No, it isn't. The 13th Amendement (which abolished slavery in the US, for those of you following along) had the net effect of making "us" more free because it dealt with the interaction between *people*. The GPL deals with the interaction between a person and *software*. Contrary to the neoligsm, a piece of software (AIs notwithstanding) cannot have freedom; only people can.
So while I mostly agree with your sentiment (that even if you take away some aspect of freedom, the net effect can be an overall increase of freedom), I disagree that the method that the 13th Amendment took to deal with the issue of slavery is "exactly analogous" to the copyleft approach to the issue of copyright because the issues themselves are not analogous.
It has nothing to do with the setting of the story. Being a fantasy doesn't excuse deus ex. Let me add some emphasis: "... the author uses a mechanism hidden from the audience (until it happens) to make something happen that shouldn't be possible (within the setting of the book)".
/should/ happen. But that's not what I mean; it's whether its happening is consistent with prior events. It doesn't even have to seem impossible; an "off-camera" character showing up just in the nick of time to save the day, with no real explanation how and why they got there just so, is a deus ex, for example.
"Shouldn't be possible" perhaps isn't the best phrasing either. You could argue that anything the author makes happen,
A fantasy novel can have internal consistency. If it doesn't, its being a fantasy is not a valid excuse.
I originally switched to Linux years ago because I had a piece of hardware that I used on a daily basis (TV tuner card) which Windows driver was incredibly buggy. Also, the Linux driver for my on-board RAID controller was much better than the Windows one.
One of my hobbies is making interesting software environments which boot from removable media or the network. While some Windows tools exist which can facilitate this, some powerful nix-only concepts like mount -o loop just don't have Windows analogs.
My favorite video player and encoder are mplayer and mencoder. While they are available for Windows, they run about twice as fast on Linux as it does on Windows (I managed to do a custom Win32 build, so it really is an apples-to-apples comparison) and some DVDs which rip fine on Linux don't work on Windows.
Scripting batch processes like image processing on my photo albums or encoding portions of my FLAC audio collection to something smaller for my portable music player is much simpler. Sure, there are a few apps that have preset functionality for something close to what I want, but nothing is ever *just right*. And while Windows does have an amazing scriptability thanks to WSH and WMI, it is much more cumbersome than shell scripts (and cmd.exe is a horrible experience to script in) and most non-MS desktop apps don't provide COM interfaces. I know what you're thinking -- most desktop users don't write scripts. True, but most desktop users would be happy to USE scripts that other people write.
Other than that, I'd be pretty happy with Windows+Cygwin.
Suspension of disbelief is one thing. Suspension of foreshadowing is a completely different matter.
Your only right to use their network is under contract with them. Break the contract, and your use of their network constitutes computer tresspassing.
Can they even demonstrate that I don't know of the existance of that malware? Maybe I installed it myself, maybe I'm monitoring it.
Then you violated your TOS and were on their network illegally.
It's your PC, but it's THEIR network. They have the right to defend their network and the obligation to protect other people using it. I'd even bet their TOS authorizes this kind of behavior.
http://www.opensecrets.org/softmoney/softtop.asp?t xtCycle=2002&txtSort=amnt
People who don't know the difference between a detail and a deus ex shouldn't comment on the literary critique of others.
I half-agree with you. They're lazy ways to get out of tricky plot points, and they therefore drag a book down.
You're right that the term "deus ex machina" comes from old great plays. But back then, it was just the machine that let characters "fly" (by attaching the actors to wires and lifting them up). That's it! The term as applied to plots is completely derogatory: the author uses a mechanism hidden from the audience to make something happen that shouldn't be possible. It's pretty much the worst thing you can say about a plot.
He was refering to the themes and morals, not to the mechanics or plotpoints. Obviously, the world being created and guided by a paganesque pantheon wouldn't mesh well with Catholicism. If you see a clash between Islam and Chritianity (or the Middle-east and Europe or whatever) when you read Tolkien, that says a lot more about you than it does about Tolkien.
Not if you follow the FSFs suggestion that every contributers transfers the ownership of the code to the original copyright holder.
... you could look at it and write your own version.
/after/ you look at the code. It's much safer just not to look.
That's an example of "asking for special permission." Also, the FSF doesn't suggest that contributers transfer ownership to the original copyright holder; they ask that everyone transfer ownership *to the FSF*.
If it is a simple security hole then while you couldn't take the patch
That's what I said.
You can, but that's legally dangerous. The problem is that what you consider obvious might not be so obvious to a judge or jury. Once you look at someone else's solution to a problem, the burden is on you to prove that your solution was developed completely independently. That's the purpose of clean-room reverse engineering, to avoid that particular legal pit.
It's much safer to just ask for a description of the problem and create a solution without looking at a GPLed patch.
Saying otherwise would be much the same as SCO saying that Linux stole a line of code from Unix that says for(i=0;i
Hyperbole is unbecoming. You cannot copyright a single line of code.
If it's just a buffer overrun caused by an improper bounds check, then you're fine. But if it's a design or algorithmic error, you have to be careful. The problem is that you don't know until
What if I were to take another GPL software like Inkscape and add a billing module, could I close source the module?
/have/ to be GPL too (and they could still sell it -- but they couldn't stop anyone they sold it to from giving it away for free).
That's a complicated quetion and there's no general-purpose answer. The problem is the legal interpretation of "derivative work". If the module is "derived" (in a legal sense as applied to software) from the Inkscape source, then no. If your module really is independent, then yes.
Take nVidia's closed-source Linux drivers, for example. They're basically a plug-in for the kernel. Some people think that because they rely on kernel internals, they are "derived" and should have to be GPL. Others think that because they're a module, they're not derived and so proprietary is OK.
Someone else taking my code then selling it, with or without bug fixes and such, without me seeing any money.
They can do that under most Free Software licenses, including GPL and BSD. But why would anyone buy it from them if they can get it from you for free? The only sensible reason would be if they had improved it somehow. If the original program were BSD, this new-and-improved version could be distributed closed-source. If the original program were GPL, the new-and-improved version would
>If you really wants to be able to sell (software including) his code,
>you can ask him for special permission to do so.
You don't need "Joe's" permission to sale software with his code do you?
I spoke sloppily. In the example, the software "you" were selling was the closed-source version. I meant that you couldn't include it in the closed-source software without his permission. You could sell it without his permission, but you would have to use the GPL to cover the whole piece of software (so anyone you sold it to could give it away for free).
That's what some people mean when they call the GPL "viral". If you include a little bit of GPL code in a large piece of software, you can't just say that it's 98% closed and 2% open. It's either all-GPL or no-GPL.
Your impression of the effects of the licenses is misguided.
Say you develop a photo-editing (or whatever) piece of software and release it under the GPL. Then you add a few new features and decide to start charging money for a closed-source version with more functionality. No problem! That is just fine.
Now consider that Joe fixes a security hole in the GPL version of your software, and the same hole exists in your closed version. You can use his patch to fix the GPL version, but you cannot use it to fix the closed version.
You see the difference? If it's your code, the GPL doesn't keep you from doing anything you want. The only thing it restricts is what you can do with Joe's code. Joe was nice enough to give you his code for free; why should you be allowed to charge other people for it?
Or, from Joe's perspective, the GPL limits what you can do with Joe's code. If you really wants to be able to sell (software including) his code, you can ask him for special permission to do so. If the code he sent you really was all his (he owns the copyright; he didn't copy it from some other GPL source), Joe could give (or sell) you permission to include the code in your closed-source software. Now that sounds fair to me.
By all means, continue disliking the GPL (I certainly don't particularly like it). But please do so for the right reasons.
Intel prefers backwards compatibility to pedantic correctness. Good for them. You, on the other hand, are just plain ignorant.
Actually, he used the term correctly. You are using it incorrectly (and so does Intel -- but they, unlike you, have a good reason). In the original 8086, a word was in fact 16 bits. As the x86 architecture expanded to a 32-bit architecture, the word size became 32 bits. To maintain backwards compatibility with documentation and compilers/assemblers, they just started calling those words "double words" (this avoided a LOT of confusion and pointless waste of effort that would have occured had they insisted on pedantry). On ia32, a "dword" is the word size of the system. When amd64 came out, AMD did the same thing for the same reasons.
The Enterprise was Constitution class.
The number of open ports is a poor metric. Windows multiplexes ports 135-139 and 445 such that just about everything goes through them. This just exacerbates the problem because you can't use a firewall to protect yourself.