[em]they're paying him a salary to give them everything he produces.[/em]
They pay him a salary to produce what they tell him to produce.
If they didn't tell him to produce an app with the given functionality, they didn't have any concrete plans to produce an app with the same functionality, and he used his own time and resources, why should they get ownership?
If the three given conditions are true, it seems to me that they're just swiping what ought to be his using the justification 'but we pay him to write other stuff'.
Yeah, it's actually stealing - but realistically, when you get caught for shoplifting the penalty will likely be less than getting caught sharing under this.
'hmm, probation/community service vs. three years in a federal pound me in the ass prison - I think I'll just shoplift'.
Strange, a hidden incentive for the unscrupulous to do something that's probably far more likely to cost businesses money than the sharing does, given that the 'sharing costs us money!' view doesn't take into consideration purchases after previewing, and that not every copy shared represents a lost sale.
Who eats the loss on a shoplifted DVD? It's the business selling the DVD, or the distributor, right? Not the company producing it. So the MPAA wouldn't care.
So Cisco should be able to take code and violate that code's license agreement?
How nice that you should allow this for Cisco and not for 'regular people'.
Let me paraphrase you, so you can see what you're actually saying:
It's much more important for Cisco to get their hands on some dope-smoking free-love hippies work than it is for Cisco to actually honor the agreement under which they used that work.
They're also entiely ignoring that it's not their house in the first place. "Burn down your house, or share it with cloners" indeed. 'Yeah, I know you let me crash at your house, but I built this deck, so it's my house now - get out'.
It shouldn't matter that it was in the trash. They've got no signature, and she recieved a card.
Here, I'll give you a check made out to your name, for $100, without my signature on it. I'll even throw it in a trash can near you, so you can make this silly 'fair game' argument. You go cash that check, and you'll end up in jail for fraud.
It's smarter to shred, but my not shredding doesn't mean you can do whatever you want without consequences.
The bigger problem is that the computers aregetting their rankings solely by playing other computers (if I'm reading the article right). The ratings are dependant on who's in the pool of players.
Say the best computer in the set of computers always beats or draws the other computers. lets say it wins more than it draws. In that pool of players, it's rating will tend to creep up.
So the ratings aren't necessarily comparable. Take a 1700 player, throw him in a pool of only 1000 players - when his rating breaks 2200(after quite a few games), that doesn't mean he'll be able to consistently beat a 2000 player, because there's no one above him in the pool he gained the 2200 rating, to lose games against and keep his rating down where it belongs.
I've no doubt computer ratings are increasing, but if there's no humans in the pool they play with there is quite concievably an effect such as this, although it's probably not as extreme.
Chess engines are basically alpha-beta searches - generate the move list, search a ply deeper, etc. Often with tricks to generate the move in a 'likely best' order.
It wouldn't work well for a seti@home type setup, but you could probably build a good cluster solution. Gen your move list, farm calculating the value of each move off to a different node, telling it how man plies to look. That node report the score of that line back to the main node, and perhaps gets a new move to look at in the meantime. the sub nodes could probably go through the same process, but you'd need a good resource allocation system - eventually you'd get to the point where one processor is doing some subset of the search on it's own (as if it were a one processor box starting from some position), but you'd gain the ability to searcgh subtrees in parallel.
Deep Blue was a multi-proc machine (with specialized processors), it's not something that can't be parallelized.
You still need a bootstrap that will go reset the memory and restart the OS.
If you don't, what's going to happen is that some bug is going to manifest itself, and it's never going to go away because you have no method resetting it - if you turn the machine off, then on, the messed up driver (or whatever) comes back in exactly the same bogus state.
Think about it. I've seen bad net (VPN) drivers for windows cause my normal networking drivers to be very slow once the vpn comes down, the only cure being a restart (when it happens, which is not often).
So now, with, as you say, the death of the concept of bootstrapping, when that happens, I'd have to live with slow network drivers/forever/. This is just one example, there are *many* more, independent of operating system (I'm unfortunately forced to use Windows for work).
You will still need the 'entire concept of bootstrapping', even if only as a cure to some other guys kernel-space bugs.
I always just figured that they planted an exploit that allows them to hook their equipment into the simulation in the code that simulates the phone system, and the 'getting in/out through the phone system that doesn't exist' was just how it manifested itelf within the simulation.
I don't believe that the somewhat underground theory that what else floats is 'very small rocks' has entirely lost credibility in the scientific community. It still has it's holdouts among various eccentric geniuses.
776 were accidental. This is entirely dwarfed by the 97,124 total accidental deaths that were not firearms related, and by the 3,482 accidental deaths by drowning, and the 13,322 accidental deaths by fall.
10,801 were homicides. For comparison, there were 5,964 homicides that were committed without a firearm. Also, 'homicide' includes justifiable homicide, the stats page I'm looking things up at doesn't let you split them apart. Some percentage of the perpertator of homicides that were not justifiable, would have found a different means to kill the intended victim.
16,586 were suicides, some percentage of which would have probably found a different way to kill themselves. In fact, 12,764 people did manage to kill themselves without a firearm, and I find it ludicrous the notion that the ones that did used firearms would have been entirely prevented if no firearms were available, considering that almost half the suicides were without a firearm.
226 were 'Legal Intervention', which does not include justifiable homicide, but is only 'legal executions and deaths caused by law officers in the line of duty.'
If you'd gladly wave your right to bear arms, move to a different country. Say, England, where the crime rate has been rising since the firearm ban, and they're now banning pellet and BB guns as though that would help.
If your motivation is to save lives, you've also got to consider the lives you'll take by removing the ability of people to own a firearm. Firearms are equalizers, a 210 pound man attempting to rape a 120 pound woman isn't going to get to use his size advantage if she's packing, a young man attempting to rob an elderly man is going to have a rough time as well, if the elderly man has a gun.
I'm not a 'selfish jerk that thinks it's cool to own a Glock'. I'm the 'selfish jerk' that will have the means to defend my family should a criminal attack them. You can call 911 and wait for the cops to show up, with no effective means to stop the criminal from hurting you, if you'd like, especially since the police are under no obligation to protect you; You are responsible for your own protection. I am responsible for mine, my wife will be calling 911 while I'm shooting the bastard, if I have to shoot him (If he decides to bug out, he'll have the chance to exit unharmed - It'll be his decision at that point).
Making guns illegal will not remove guns from the hands of criminals, it will only remove them from the hands of law-abiding citizens, leaving them less able to defend themselves when the criminals, who will have guns regardless of their legality, attempt to take advantage of them.
xant, this post is not necessarily aimed entirely at you, I have no idea if you have a swimming pool... your post just happened to be the one that made me want to post.
Do you realize how few children actually accidentally shoot themselves?
Check unintentional under 1. Check 'firearm' under 2. Select custom age range, put seventy million children were accidentally killed with firearms.
For 2000, the number is 150.
Each one of those deaths was tragic, true, but children killing themselves with guns is not the huge problem the anti-gun groups would have you believe it to be.
In fact, in 1999, one thousand one hundred twenty seven children accidentally drowned - Almost ten times the number of accidental firearms deaths for the same age range.
If you teach your children the dangers of firearms, the chances of them being involved in an accident will be reduced, whether you own a firearm or not.
If my guns are not under my immediate control, they are locked up in the safe. My kids will be taught gun safety as soon as they're old enough to understand.
If you need a legitimate way to gain access for debugging purpose, document it as part of the system, don't code it up and leave it a secret. It then won't really be a backdoor, and the access to it can be controlled appropriately.
Coding up a backdoor and leaving it undocumented is a bunch of crap - you're probably not going to remember to disable it, you're probably going to get onto the next project and forget about it entirely, leaving it there for others to potentially find - others who are potentially hostile.
Plus, if you don't leave a secret back door there's no temptation to use said secret back door to get even once you get laid off, saving you from potential jail time:)
I've never written any backdoors into any of the code I've written. It's entirely unethical. The fact that he took such an action is proof that he's not ethical, get rid of him.
A smart business therefore asks not whether the use of its content is "theft," but whether the use of its content will (eventually at least) benefit it.... is it just me or doues this sound like the definition of business for it's own sake?
I think you're missing the point a bit. If a business owns the content, it can look at the cases of unauthorized use of it's content, and say, 'hey, this use is actually benifitting me, even though it's using my characters and I could likely sue the pants off them if I so wished. Since it benefits me, I think I won't sue them'. This is a far cry from 'business for it's own sake', which to me would mean something to the effect of 'hey, this is entirely unethical and probably illegal, but it makes me money, so it must be ok!'.
I remember the hydrostatic shock theory from the Vietnam era -- it was the explanation for why a light-calibre gun like the M16 was effective in combat
I do not know if it's true, but when I was in boot camp, one of our firearms instructors told us that the M16 spun the bullet lightly enough that it would be stable while in flight, but destabilize and start tumbling when it hit the target, thus doing more damage (due to the tumbling, etc). I don't know enough about ballistics to know if this makes any real sense, but it makes more sense to me than the hydrostatic shock theory - Isn't this somewhat the same concept as a hollow point round -> expansion on impact, thus causing more physical damage (vs. destabilization on impact, causing more physical damage).
Of course, it's entirely possible that the instructor was merely repeating pseudo-scientific bullshit that he'd heard second-hand from someone else...
I don't disagree with your points or overall perspective, but thought I'd toss out one fairly simple "reduce the odds" step that deals with one of the key issues you raised.
It's actually all about reducing the odds ->
a step such as you suggest is not a bad idea. I was trying to point out that as you go about reducing the odds, you should also keep in mind the fact that you're never going to make it impossible (which should drive you to reduce the odds further, which should...). I should have probably stated that more explicitly, the original post read to me somewhat like 'Well, if you do this, this and this you'll be just fine!', which wasn't necessarily how it was intended, just how it came across to me.
Departments do this all the time, with much more complex code. Those departments are collectively called "Software Engineering". It may be impossible to grasp by IT departments, but it is possible, and desired, to review every line of code making its way into the system.
I agree with this, every line of code should be reviewed before it makes it into the system. However, note that i said a line-by-line code/config review of -everything- every single time a change is made, which is different from ensuring that every line is reviewed prior to making it's way into the system. I.E., it's the difference between :
a) reviewing a million lines of code in smaller chunks as they are being written, and then reviewing the relevant code related to a four-line bug fix. (including not just the four lines but related code in that execution path/module/etc.)
and
b) Making a four line bug fix and then reviewing, line by line, the entire million lines of code.
I could see the second approach being taken for certain applications, however, the company doing so would have to hire a team -just to do the code reviews-. (This doesn't actually sound like a bad idea... hmmmm... I wish my company could afford it...). Most departments, software engineering or no, don't have the resources for this, therefore, it's impractical. You grok?
Slashdot Mirror
[em]they're paying him a salary to give them everything he produces.[/em]
They pay him a salary to produce what they tell him to produce.
If they didn't tell him to produce an app with the given functionality, they didn't have any concrete plans to produce an app with the same functionality, and he used his own time and resources, why should they get ownership?
If the three given conditions are true, it seems to me that they're just swiping what ought to be his using the justification 'but we pay him to write other stuff'.
Well, the hidden nasties sometimes make their way into the backups.
Ahh. Now I grok.
Yeah, it's actually stealing - but realistically, when you get caught for shoplifting the penalty will likely be less than getting caught sharing under this.
'hmm, probation/community service vs. three years in a federal pound me in the ass prison - I think I'll just shoplift'.
Strange, a hidden incentive for the unscrupulous to do something that's probably far more likely to cost businesses money than the sharing does, given that the 'sharing costs us money!' view doesn't take into consideration purchases after previewing, and that not every copy shared represents a lost sale.
Who eats the loss on a shoplifted DVD? It's the business selling the DVD, or the distributor, right? Not the company producing it. So the MPAA wouldn't care.
I don't think it's significant.
The source code itself wouldn't use fonts, it's a plain text file. No font information.
She probably pushed it a bunch of times and now thinks her Dad is an idiot ;)
So Cisco should be able to take code and violate that code's license agreement?
How nice that you should allow this for Cisco and not for 'regular people'.
Let me paraphrase you, so you can see what you're actually saying:
It's much more important for Cisco to get their hands on some dope-smoking free-love hippies work than it is for Cisco to actually honor the agreement under which they used that work.
They're also entiely ignoring that it's not their house in the first place. "Burn down your house, or share it with cloners" indeed. 'Yeah, I know you let me crash at your house, but I built this deck, so it's my house now - get out'.
It shouldn't matter that it was in the trash. They've got no signature, and she recieved a card.
Here, I'll give you a check made out to your name, for $100, without my signature on it. I'll even throw it in a trash can near you, so you can make this silly 'fair game' argument. You go cash that check, and you'll end up in jail for fraud.
It's smarter to shred, but my not shredding doesn't mean you can do whatever you want without consequences.
The bigger problem is that the computers aregetting their rankings solely by playing other computers (if I'm reading the article right). The ratings are dependant on who's in the pool of players.
Say the best computer in the set of computers always beats or draws the other computers. lets say it wins more than it draws. In that pool of players, it's rating will tend to creep up.
So the ratings aren't necessarily comparable. Take a 1700 player, throw him in a pool of only 1000 players - when his rating breaks 2200(after quite a few games), that doesn't mean he'll be able to consistently beat a 2000 player, because there's no one above him in the pool he gained the 2200 rating, to lose games against and keep his rating down where it belongs.
I've no doubt computer ratings are increasing, but if there's no humans in the pool they play with there is quite concievably an effect such as this, although it's probably not as extreme.
Chess engines are basically alpha-beta searches - generate the move list, search a ply deeper, etc. Often with tricks to generate the move in a 'likely best' order.
It wouldn't work well for a seti@home type setup, but you could probably build a good cluster solution. Gen your move list, farm calculating the value of each move off to a different node, telling it how man plies to look. That node report the score of that line back to the main node, and perhaps gets a new move to look at in the meantime. the sub nodes could probably go through the same process, but you'd need a good resource allocation system - eventually you'd get to the point where one processor is doing some subset of the search on it's own (as if it were a one processor box starting from some position), but you'd gain the ability to searcgh subtrees in parallel.
Deep Blue was a multi-proc machine (with specialized processors), it's not something that can't be parallelized.
Well, I don't think so, actually.
/forever/. This is just one example, there are *many* more, independent of operating system (I'm unfortunately forced to use Windows for work).
You still need a bootstrap that will go reset the memory and restart the OS.
If you don't, what's going to happen is that some bug is going to manifest itself, and it's never going to go away because you have no method resetting it - if you turn the machine off, then on, the messed up driver (or whatever) comes back in exactly the same bogus state.
Think about it. I've seen bad net (VPN) drivers for windows cause my normal networking drivers to be very slow once the vpn comes down, the only cure being a restart (when it happens, which is not often).
So now, with, as you say, the death of the concept of bootstrapping, when that happens, I'd have to live with slow network drivers
You will still need the 'entire concept of bootstrapping', even if only as a cure to some other guys kernel-space bugs.
I always just figured that they planted an exploit that allows them to hook their equipment into the simulation in the code that simulates the phone system, and the 'getting in/out through the phone system that doesn't exist' was just how it manifested itelf within the simulation.
:)
No big deal.
I don't believe that the somewhat underground theory that what else floats is 'very small rocks' has entirely lost credibility in the scientific community. It still has it's holdouts among various eccentric geniuses.
How many people die from guns each year
Well, for the year two thousand, it was 28,663 deaths.
776 were accidental. This is entirely dwarfed by the 97,124 total accidental deaths that were not firearms related, and by the 3,482 accidental deaths by drowning, and the 13,322 accidental deaths by fall.
10,801 were homicides. For comparison, there were 5,964 homicides that were committed without a firearm. Also, 'homicide' includes justifiable homicide, the stats page I'm looking things up at doesn't let you split them apart. Some percentage of the perpertator of homicides that were not justifiable, would have found a different means to kill the intended victim.
16,586 were suicides, some percentage of which would have probably found a different way to kill themselves. In fact, 12,764 people did manage to kill themselves without a firearm, and I find it ludicrous the notion that the ones that did used firearms would have been entirely prevented if no firearms were available, considering that almost half the suicides were without a firearm.
226 were 'Legal Intervention', which does not include justifiable homicide, but is only 'legal executions and deaths caused by law officers in the line of duty.'
If you'd gladly wave your right to bear arms, move to a different country. Say, England, where the crime rate has been rising since the firearm ban, and they're now banning pellet and BB guns as though that would help.
If your motivation is to save lives, you've also got to consider the lives you'll take by removing the ability of people to own a firearm. Firearms are equalizers, a 210 pound man attempting to rape a 120 pound woman isn't going to get to use his size advantage if she's packing, a young man attempting to rob an elderly man is going to have a rough time as well, if the elderly man has a gun.
I'm not a 'selfish jerk that thinks it's cool to own a Glock'. I'm the 'selfish jerk' that will have the means to defend my family should a criminal attack them. You can call 911 and wait for the cops to show up, with no effective means to stop the criminal from hurting you, if you'd like, especially since the police are under no obligation to protect you; You are responsible for your own protection. I am responsible for mine, my wife will be calling 911 while I'm shooting the bastard, if I have to shoot him (If he decides to bug out, he'll have the chance to exit unharmed - It'll be his decision at that point).
Making guns illegal will not remove guns from the hands of criminals, it will only remove them from the hands of law-abiding citizens, leaving them less able to defend themselves when the criminals, who will have guns regardless of their legality, attempt to take advantage of them.
Statistically, half of the households in the United States own a firearm. If firearms are the huge problem that the anti-gun organizations would have you believe, we'd all be dead already. Also, I find it somewhat interesting that HCI (Now the Brady Campaign) was apparently founded by a man who allegedly kept two handguns buried in his back yard, and owned a rifle as well (no it was not founded by Sara Brady)
"Select custom age range, put seventy million children were accidentally killed with firearms."
... it's actually somewhat funny.
should be
"Select custom age range, put <1 to 17.
Select he year 1999. 158 out of seventy million children were accidentally killed with firearms."
Something like that is what I originally typed, it came out hosed because of the <
xant, this post is not necessarily aimed entirely at you, I have no idea if you have a swimming pool ... your post just happened to be the one that made me want to post.
l
Do you realize how few children actually accidentally shoot themselves?
http://webapp.cdc.gov/sasweb/ncipc/mortrate10.htm
Check unintentional under 1.
Check 'firearm' under 2.
Select custom age range, put seventy million children were accidentally killed with firearms.
For 2000, the number is 150.
Each one of those deaths was tragic, true, but children killing themselves with guns is not the huge problem the anti-gun groups would have you believe it to be.
In fact, in 1999, one thousand one hundred twenty seven children accidentally drowned - Almost ten times the number of accidental firearms deaths for the same age range.
If you teach your children the dangers of firearms, the chances of them being involved in an accident will be reduced, whether you own a firearm or not.
If my guns are not under my immediate control, they are locked up in the safe. My kids will be taught gun safety as soon as they're old enough to understand.
Does your swimming pool have a cover?
Bridgekeeper: What is your favorite UNIX flavor? ... aaaaaaaaaauuuggh!
SCO: SCO Openserver. No, Linux. No, System V
If you need a legitimate way to gain access for debugging purpose, document it as part of the system, don't code it up and leave it a secret. It then won't really be a backdoor, and the access to it can be controlled appropriately.
:)
Coding up a backdoor and leaving it undocumented is a bunch of crap - you're probably not going to remember to disable it, you're probably going to get onto the next project and forget about it entirely, leaving it there for others to potentially find - others who are potentially hostile.
Plus, if you don't leave a secret back door there's no temptation to use said secret back door to get even once you get laid off, saving you from potential jail time
and fire him fast.
I've never written any backdoors into any of the code I've written. It's entirely unethical. The fact that he took such an action is proof that he's not ethical, get rid of him.
Five years in prison to get fame and perpetual job security? I'd do it in a heartbeat.
Get to it then. I'm sure we'll see you on the six o'clock news shortly.
A smart business therefore asks not whether the use of its content is "theft," but whether the use of its content will (eventually at least) benefit it. ... is it just me or doues this sound like the definition of business for it's own sake?
I think you're missing the point a bit. If a business owns the content, it can look at the cases of unauthorized use of it's content, and say, 'hey, this use is actually benifitting me, even though it's using my characters and I could likely sue the pants off them if I so wished. Since it benefits me, I think I won't sue them'. This is a far cry from 'business for it's own sake', which to me would mean something to the effect of 'hey, this is entirely unethical and probably illegal, but it makes me money, so it must be ok!'.
I remember the hydrostatic shock theory from the Vietnam era -- it was the explanation for why a light-calibre gun like the M16 was effective in combat
I do not know if it's true, but when I was in boot camp, one of our firearms instructors told us that the M16 spun the bullet lightly enough that it would be stable while in flight, but destabilize and start tumbling when it hit the target, thus doing more damage (due to the tumbling, etc). I don't know enough about ballistics to know if this makes any real sense, but it makes more sense to me than the hydrostatic shock theory - Isn't this somewhat the same concept as a hollow point round -> expansion on impact, thus causing more physical damage (vs. destabilization on impact, causing more physical damage).
Of course, it's entirely possible that the instructor was merely repeating pseudo-scientific bullshit that he'd heard second-hand from someone else...
I don't disagree with your points or overall perspective, but thought I'd toss out one fairly simple "reduce the odds" step that deals with one of the key issues you raised.
...). I should have probably stated that more explicitly, the original post read to me somewhat like 'Well, if you do this, this and this you'll be just fine!', which wasn't necessarily how it was intended, just how it came across to me.
It's actually all about reducing the odds -> a step such as you suggest is not a bad idea. I was trying to point out that as you go about reducing the odds, you should also keep in mind the fact that you're never going to make it impossible (which should drive you to reduce the odds further, which should
Departments do this all the time, with much more complex code. Those departments are collectively called "Software Engineering". It may be impossible to grasp by IT departments, but it is possible, and desired, to review every line of code making its way into the system.
I agree with this, every line of code should be reviewed before it makes it into the system. However, note that i said
a line-by-line code/config review of -everything- every single time a change is made, which is different from ensuring that every line is reviewed prior to making it's way into the system. I.E., it's the difference between :
a) reviewing a million lines of code in smaller chunks as they are being written, and then reviewing the relevant code related to a four-line bug fix. (including not just the four lines but related code in that execution path/module/etc.)
and
b) Making a four line bug fix and then reviewing, line by line, the entire million lines of code.
I could see the second approach being taken for certain applications, however, the company doing so would have to hire a team -just to do the code reviews-. (This doesn't actually sound like a bad idea... hmmmm... I wish my company could afford it...). Most departments, software engineering or no, don't have the resources for this, therefore, it's impractical. You grok?