Okay, the correct answer is "go cold turkey", because switching to tea will still give you some of the withdrawal symptoms -- coffee is really, really nasty stuff, even decaf. But anyhow, tea will provide a good substitute, a good habit-filler, and is apparently not addictive (although anything will become a habit if you do it enough).
You'll ingest a fraction of the caffeine, you'll get less of the other nasty stuff that's in coffee (caffeine isn't the only 'upper' in coffee), and you'll get some positive benefits -- antioxidants, tooth decay slowing, bad breath reduction, and so on.
Personally I do a fair bit of research and I find no use for tabs. I can only read one screen at a time so I don't care for tabs.
This is why I use tabs -- I can only read one page at a time, but I want to check hyperlinks. So I open them in tabs, and when I'm ready to take my attention off of what I'm reading, they're ready for me.
Of course, tabs are also handy for bookmarks -- my daily news reading is a bookmark that opens up a set of tabs.
I don't know how to reliably detect when you're "ignoring" email; if you figure out a way, that would be handy. In the meantime, Mozilla Firebird now has a patch to apply Bayesian learning to moving emails from the main folder to any other folder -- so spam classification is just a subset of email classification, and training is just as simple as what you'd have to do anyways -- just move the message into the folder you'd want messages like it to appear in.
They did encrypt the signal, and also spread-spectrum'ed it.
But you wouldn't get anything useful with your shortwave receiver; the broadcating antenna's geometry is all wrong for radio waves. I'm not sure, but IIRC your receiving antenna would have to be pretty scary, too. IANAH (I am not a ham).
Yes, null pointers are logic errors. Allowing them is a logic error. Putting them in an API is a logic error.
Don't use null pointers.
Unless you're stuck with C, of course.
The problem with nulls is that they can hide for a LONG time before they finally reveal themselves. There are two replacements: exceptions and "null objects". Exceptions should be used when a null pointer would have been returned to indicate an error; null objects can be used when a object representation of "no such object" is actually needed.
Both have their risks, but both are far safer than null pointers.
-Billy
Re:Idiocy - bluetooth just taking off
on
Is Bluetooth Dead?
·
· Score: 1
But what I'd really like to know is why this is the case in the US.
I'm told that the problem is that the US has almost 100% coverage with its existing phone system; Europe didn't, so when it came down to spending money on old versus new tech, the new tech won -- and with the terrain in some parts of Europe, wireless was a LOT easier to install.
I like the looks of B-field communications, as in AuraComm's devices. They're not replacements for Bluetooth (since their range is so small, 3 meters at most), but they do eat up a lot of its potential market, with much, much lower power draw and much simpler support circuitry.
Bluetooth is, in the long term, a VERY narrow niche, even if B-field communications never takes off.
Ugh, no. The fewer functions in each class, the better the API looks and works cognitively.
You can still keep all your API functions in one place -- a namespace, or a header file that includes the original class -- but if you cram them in the original class you're making it certain that 90% of the class will be useless to every programmer that uses it, and will therefore be a waste of cognitive effort. The wasted effort means that people will be reluctant to learn your API, and therefore it won't be used as much, thereby causing the EXACT problem you're trying to avoid.
This is only the start of the problems. Next come the purely technical problems, like inheriting from gargantuan classes, or designing extensions which fit into the spirit of the class (C++'s own STL has at least one class that contains over 50 methods, many of them with oddly contradictory calling patterns). I won't go on...
No, I can't see that helping -- because it would lower the response rate of the ads, thereby earning less per clickthrough. And the clickthrough rates are already terribly low.
Plus, if this does become widespread, the solution's simple: just have the automatic visiter be a little smarter about whom it downloads stuff from. You should only download stuff from blacklisted sites.
(I'm not sure I like this plan anyhow, since I think it's ridiculously aggressive; but the foundation should work very well.)
the best way to deliver software effectively is to understand the problem domain.
I agree with you, and it seems that XP agrees with you. The difference is that XP doesn't assume that you can afford to become an expert BEFORE you do any work in the problem domain, and XP admits that the final expert in the problem domain is the person who's having the problem.
The ONE original idea in XP is simple...
I agree that XP contains almost no new ideas... I think the only really new thing is simply the synthesis.
You don't need requirements before you start coding.
Whoah. Where'd you get that idea? That's not part of XP -- on the contrary, doing XP without User Stories would be... bizzarre. No, impossible. All of the practices are built around NOT writing code that doesn't solve a user story.
XP assumes the John Wayne school of hacking, just hack hack and your talent will get you through.
Nope, XP is a documented process requiring discipline and support. I've seen it elaborated to CMM level 5, although I've never seen it used at that level. If you follow it as documented in the typical XP references, you'll be operating at just under CMM level 3; to get to level 3 you'll have to formalise a few things and write some documentation. Several level 4 KPAs are also addressed by basic XP practices.
4 times? Cite your source, please. The rest of that paragraph seems equally unlikely (I've seen positive reviews of PP, including one positive study), but I'll let that float until I get a backup to that number.
Also, refactoring can be good, but it takes a lot of time and effort to make code cleanly work, and that effort is usually duplicated when you re-factor. The cost in time is HUGE, and it should not be taken lightly.
You're confusing refactoring with rewriting, aren't you?
The hard core, nitty-gritty, down and dirty facts are that the use of XP is four times as slow, irritating as can possibly be, and would not EVER be allowed by the vast majority of seasoned programmers.
These are not facts, mister. They're not even true; all but the last bear not the faintest nodding acquaintance with reality. The second has the dignity of being mere opinion, but it's patently obvious that it's not a tenable opinion for anyone who's experienced any of the programming world -- no matter WHAT your preferences are, there are FAR worse abuses to suffer under than XP's benevolent regime. The first is, of course, out-and-out false.
Next time you are programming think of what it would be like to have someone looking over your shoulder arguing about class definitions or variable names.
It hurts when you do that -- don't do that. Don't hire programmers who never shower, either. If you get a dud, fire him.
Seriously, industry best practice is peer review. Pair programming is a chance to do peer review constantly, NOTHING MORE. If you can do a peer review right, you can also do pair programming right.
Projects take two programmers twice the time as the better of the two would use to do it alone.
No, but a FAR closer brush with the truth than before. Empirically, each task takes a little shorter than the best of the two would have taken, BUT the quality of the code produced is dramatically higher, resulting in fewer tasks needed to get the same functionality (less bug-catching, less rework to add missed functionality) and much lower maintenance costs -- and remember, maintenance accounts for the vast majority of the cost of a project.
The overall cost, up to but not including maintenance, of a project incorporating pair programming but not other parts of XP, seems to be about the same as non-pair programming.
The best is when you get stuck halfway through a re-factor and just waste time backing the changes out so the code works again.
Backing changes out is easy. Just thank your lucky stars that you have version control and a solid, well-used and maintained test suite. The "best" part is when you're working on aged, un-refactored code and have no choice but to accept it, because you've decided not to refactor!
XP is a solution looking for a problem, it probably needs refactoring itself.
News flash: the problem's here, and it's been here a long time. Don't know if XP is a solution.
Next time someone recommends it, ask for a successful neutral third party evaluation (ie: one not associated with the XP program). You won't find such a positive eval because they do not exist.
What is "the XP program"? Or are you just referring to anyone who's said anything positive about XP?
Other than that: yes, there is a paucity of studies on XP; whether good, bad, or ugly. There have been a few studies on some of the components of XP, such as pair programming (my statements above are based on one such). Most of what you can find is groundless ranting.
Look for the people who've tried it. Personally, I've done everything but pair programming. My personal process now includes Test-Driven-Development just as a default, with other elements incorporated as I have the opportunity.
You don't need batteries if you're on the grid -- you only need a good inverter to match you up with the grid's phase, and you'll wind up supplying power to the grid during your best generation hours (which happen to match up with their peak demand/most expensive hours), and taking it during their cheapest hours.
Most companies (possibly all) can bill you according to peak/off peak usage and contribution; so you can use as much as you want at night, and your daytime contribution will pay for it.
Actually, a spending increase would definitely improve student performance. Spending more on education leads to more qualified teachers, better facilities, and smaller classes, all of which contribute to a better learning environment.
This fails to be backed by history. Spending more means more administration, more regulation, more teaching to standardised tests, and more lobbying to reduce those standards and remove legitimate competition.
Well, it doesn't ALWAYS mean that:-) -- but there are plenty of examples where that's exactly what happened, so your statement certainly should be amended to eliminate the word "definitely", and should include some discussion of how to solve the real problems, rather than just dumping more money onto them.
I'm not against more money for education, of course; you ARE correct that it's needed. But it has to actually make it to the classes, and it has to be used wisely -- and right now, in most states of the US that's impossible.
And now fluorescent bulbs are becoming available for almost as cheap as a regular bulb, lasting longer, and using less electricity.
Yeah, companies are short-sighted -- but all it takes is ONE farsighted entrepreneur, and the short-sighted companies have to switch over or die. The customers can only buy what's available, but if you start providing what they want they'll pay you.
It's amazing how many people now are chanting, "you can't trust the free market!" This is based on truth, but is the exact opposite of the problem we're facing -- you're suggesting something very like pouring gasoline on a fire, or water on sodium (or both).
The problems are manifold. Do you get locked up because a person you had ordered from spammed? Do you get locked up if you ordered directly because of a spam? How do they prove that you ordered because of a spam?
And would this have the same success as the War on Drugs?
1) The fail scenarios of space elevators are not very good. Think about the possible fail scenarios from the various areas: political, military, natural disaster, engineering. Consider the impacts and probabilities.
Cable break, you mean? Yup, that's bad. I don't think it's impossible to work around, but I agree that it has to be fully worked out before we implement. Good thing we have a few decades.
_Normal_ operation of a space elevator is clearly very safe, and therefore attractive. Catastrophic operation, however, desperately needs to be worked out.
2) Space elevators only get you up to geostationary (and maybe 2X), they don't get you much further than that.
Wrong. Once you're past geostationary, you're a slingshot, not just an elevator. You've got a LOT of options, anything in a plane with Earth's equator. And, of course, once you're well away from Earth you can use other options, like project Orion's nuke propulsion.
Why would SCO's action cause everyone to stop using it?
Exactly my point. SCO's illegal actions can't stop _anyone_ from using Linux unless they can stop _everyone_ from using it.
You were also making a mistake when you said that SCO had to recall its product from its customers. Think about it -- who is SCO's customers? The answer isn't "everyone who's paid SCO money," because money isn't part of the violation. The answer is "everyone who's received illegal code from SCO." Guess what? If SCO's right, that's ALL of us.
Of course, like you, I don't think SCO's right. Well, I don't think it's substantially right; I think there's so much error, and the error goes both ways. If SCO survives this (and thanks to IBM, it won't), Linux will be freed, mostly by declarations of public domain and partly by removing SCO code.
I admit that there's a theory about copyright law that claims that the law covers use. The problem is that if it's true, the GPL itself is invalid, or at least seriously lacking.
Either we ALL have to stop using Linux because SCO is using it to violate the law, or only SCO does. Which one makes sense to you?
Read the GPL -- it specifically states that nothing can affect the right to use the software, only to distribute it.
Now, that might possibly NOT be what copyright law actually _means_ -- but that's what the people who use the GPL want their users to do. Thus, the people who contributed to the kernel explicitly allow use, regardless of other violations. (Not to mention that the GPL's drafters might have been right that copyright law DOES allow use without license.)
Of course, THEN they get trod on by their own customers (what few they have left), who are suddenly without official support.
Correct -- I didn't say it would be easy, just simple. Every engineer knows that the two are opposites.
IIRC, SCO can't distribute Linux at all while violating the GPL like this.
Yup! All gone. No more customers.
I didn't mention that at least some of the customers might have grounds to sue for violation of contract, since SCO had to stop supporting them -- but I'm not sure what was in SCO's contracts. SCO would definitely be liable, since their actions led directly to them being unable to provide support.
SCO could very well be in a catch-22, unless their contracts with their customers are ALL completely free of continuing-support obligation. (And THAT would be a funny catch-22 itself, considering what they've said about indemnification!)
so other people could sue those customers for using IP that they do not actually have a licence for.
No. The GPL is very explicit that it does not affect use; it allows it because copyright law allows it.
So SCO's customers don't need to know about the GPL, don't have to stop using, or anything else -- unless, of course, SCO rescinds their license to _its_ non-GPLed code.
But there's nothing in the GPL or copyright law that can force SCO to do _that_.
So no, SCO doesn't have to recall anything, only stop the violation.
You may not oppress anyone, morally or otherwise. The Constitution grants power like that to "the people" as a whole under the formal arrangements of a government with limited powers.
If my society acts with my approval, I am morally responsible. Thus, I may be said to oppress anyone that my government oppresses with my approval. You can't hide behind "the people", and I refuse to.
Man, what is with people that they want to wield power over others? Is everybody power-hungry in this society?
Ad hominem -- and beside the point. I wasn't saying that, I was quoting you to demonstrate your error. You're using loaded terms in a very misleading way.
Every time you try to restrict corporate speech they will use that argument and they will win as long as they are considered persons.
You're going to lose if you keep that argument -- corporations ARE persons, and will always be. The question is whether artificial persons, AKA "merely legal persons" have the same rights as natural persons. THAT is an interesting and worthy question; the answer seems to be an obvious NO, but it's not clear to me exactly what rights they do and don't possess.
Mucking around with hair-splitting laws that attempt to target certain speech and not others will just muddy the waters and lead to endless litigation.
No, doing anything that costs someone else money will cause litigation. What do you expect?
There is absolutely NO reason why a law has to restrict ALL unwanted bad behavior at the same time. If it's okay to restrict ALL unwanted money-gathering calls, it's also okay to restrict a subset of them under the same conditions.
It would also be okay to require telemarketers to have licenses and meet certain requirements.
Slashdot Mirror
The higher the investment you made in learning something the harder you'll vouch for it, wether it's good or not.
And the less you know, the more competant you imagine you are.
Do you have any reason to suspect that the original poster is wrong? I.e. do you believe it's good or not?
Or were you just wasting electrons?
-Billy
Okay, the correct answer is "go cold turkey", because switching to tea will still give you some of the withdrawal symptoms -- coffee is really, really nasty stuff, even decaf. But anyhow, tea will provide a good substitute, a good habit-filler, and is apparently not addictive (although anything will become a habit if you do it enough).
You'll ingest a fraction of the caffeine, you'll get less of the other nasty stuff that's in coffee (caffeine isn't the only 'upper' in coffee), and you'll get some positive benefits -- antioxidants, tooth decay slowing, bad breath reduction, and so on.
-Billy
Personally I do a fair bit of research and I find no use for tabs. I can only read one screen at a time so I don't care for tabs.
This is why I use tabs -- I can only read one page at a time, but I want to check hyperlinks. So I open them in tabs, and when I'm ready to take my attention off of what I'm reading, they're ready for me.
Of course, tabs are also handy for bookmarks -- my daily news reading is a bookmark that opens up a set of tabs.
-Billy
I don't know how to reliably detect when you're "ignoring" email; if you figure out a way, that would be handy. In the meantime, Mozilla Firebird now has a patch to apply Bayesian learning to moving emails from the main folder to any other folder -- so spam classification is just a subset of email classification, and training is just as simple as what you'd have to do anyways -- just move the message into the folder you'd want messages like it to appear in.
Check out my feature request on Bugzilla, bug 181866, for more information. And vote for it!
-Billy
They did encrypt the signal, and also spread-spectrum'ed it.
But you wouldn't get anything useful with your shortwave receiver; the broadcating antenna's geometry is all wrong for radio waves. I'm not sure, but IIRC your receiving antenna would have to be pretty scary, too. IANAH (I am not a ham).
-Billy
Yes, null pointers are logic errors. Allowing them is a logic error. Putting them in an API is a logic error.
Don't use null pointers.
Unless you're stuck with C, of course.
The problem with nulls is that they can hide for a LONG time before they finally reveal themselves. There are two replacements: exceptions and "null objects". Exceptions should be used when a null pointer would have been returned to indicate an error; null objects can be used when a object representation of "no such object" is actually needed.
Both have their risks, but both are far safer than null pointers.
-Billy
But what I'd really like to know is why this is the case in the US.
I'm told that the problem is that the US has almost 100% coverage with its existing phone system; Europe didn't, so when it came down to spending money on old versus new tech, the new tech won -- and with the terrain in some parts of Europe, wireless was a LOT easier to install.
But I'm no expert on this.
-Billy
I like the looks of B-field communications, as in AuraComm's devices. They're not replacements for Bluetooth (since their range is so small, 3 meters at most), but they do eat up a lot of its potential market, with much, much lower power draw and much simpler support circuitry.
Bluetooth is, in the long term, a VERY narrow niche, even if B-field communications never takes off.
-Billy
this creates an API that sucks
...
Ugh, no. The fewer functions in each class, the better the API looks and works cognitively.
You can still keep all your API functions in one place -- a namespace, or a header file that includes the original class -- but if you cram them in the original class you're making it certain that 90% of the class will be useless to every programmer that uses it, and will therefore be a waste of cognitive effort. The wasted effort means that people will be reluctant to learn your API, and therefore it won't be used as much, thereby causing the EXACT problem you're trying to avoid.
This is only the start of the problems. Next come the purely technical problems, like inheriting from gargantuan classes, or designing extensions which fit into the spirit of the class (C++'s own STL has at least one class that contains over 50 methods, many of them with oddly contradictory calling patterns). I won't go on
-Billy
No, I can't see that helping -- because it would lower the response rate of the ads, thereby earning less per clickthrough. And the clickthrough rates are already terribly low.
Plus, if this does become widespread, the solution's simple: just have the automatic visiter be a little smarter about whom it downloads stuff from. You should only download stuff from blacklisted sites.
(I'm not sure I like this plan anyhow, since I think it's ridiculously aggressive; but the foundation should work very well.)
-Billy
the best way to deliver software effectively is to understand the problem domain.
... bizzarre. No, impossible. All of the practices are built around NOT writing code that doesn't solve a user story.
I agree with you, and it seems that XP agrees with you. The difference is that XP doesn't assume that you can afford to become an expert BEFORE you do any work in the problem domain, and XP admits that the final expert in the problem domain is the person who's having the problem.
The ONE original idea in XP is simple...
I agree that XP contains almost no new ideas... I think the only really new thing is simply the synthesis.
You don't need requirements before you start coding.
Whoah. Where'd you get that idea? That's not part of XP -- on the contrary, doing XP without User Stories would be
XP assumes the John Wayne school of hacking, just hack hack and your talent will get you through.
Nope, XP is a documented process requiring discipline and support. I've seen it elaborated to CMM level 5, although I've never seen it used at that level. If you follow it as documented in the typical XP references, you'll be operating at just under CMM level 3; to get to level 3 you'll have to formalise a few things and write some documentation. Several level 4 KPAs are also addressed by basic XP practices.
-Billy
4 times? Cite your source, please. The rest of that paragraph seems equally unlikely (I've seen positive reviews of PP, including one positive study), but I'll let that float until I get a backup to that number.
Also, refactoring can be good, but it takes a lot of time and effort to make code cleanly work, and that effort is usually duplicated when you re-factor. The cost in time is HUGE, and it should not be taken lightly.
You're confusing refactoring with rewriting, aren't you?
-Billy
The hard core, nitty-gritty, down and dirty facts are that the use of XP is four times as slow, irritating as can possibly be, and would not EVER be allowed by the vast majority of seasoned programmers.
These are not facts, mister. They're not even true; all but the last bear not the faintest nodding acquaintance with reality. The second has the dignity of being mere opinion, but it's patently obvious that it's not a tenable opinion for anyone who's experienced any of the programming world -- no matter WHAT your preferences are, there are FAR worse abuses to suffer under than XP's benevolent regime. The first is, of course, out-and-out false.
Next time you are programming think of what it would be like to have someone looking over your shoulder arguing about class definitions or variable names.
It hurts when you do that -- don't do that. Don't hire programmers who never shower, either. If you get a dud, fire him.
Seriously, industry best practice is peer review. Pair programming is a chance to do peer review constantly, NOTHING MORE. If you can do a peer review right, you can also do pair programming right.
Projects take two programmers twice the time as the better of the two would use to do it alone.
No, but a FAR closer brush with the truth than before. Empirically, each task takes a little shorter than the best of the two would have taken, BUT the quality of the code produced is dramatically higher, resulting in fewer tasks needed to get the same functionality (less bug-catching, less rework to add missed functionality) and much lower maintenance costs -- and remember, maintenance accounts for the vast majority of the cost of a project.
The overall cost, up to but not including maintenance, of a project incorporating pair programming but not other parts of XP, seems to be about the same as non-pair programming.
The best is when you get stuck halfway through a re-factor and just waste time backing the changes out so the code works again.
Backing changes out is easy. Just thank your lucky stars that you have version control and a solid, well-used and maintained test suite. The "best" part is when you're working on aged, un-refactored code and have no choice but to accept it, because you've decided not to refactor!
XP is a solution looking for a problem, it probably needs refactoring itself.
News flash: the problem's here, and it's been here a long time. Don't know if XP is a solution.
Next time someone recommends it, ask for a successful neutral third party evaluation (ie: one not associated with the XP program). You won't find such a positive eval because they do not exist.
What is "the XP program"? Or are you just referring to anyone who's said anything positive about XP?
Other than that: yes, there is a paucity of studies on XP; whether good, bad, or ugly. There have been a few studies on some of the components of XP, such as pair programming (my statements above are based on one such). Most of what you can find is groundless ranting.
Look for the people who've tried it. Personally, I've done everything but pair programming. My personal process now includes Test-Driven-Development just as a default, with other elements incorporated as I have the opportunity.
-Billy
You don't need batteries if you're on the grid -- you only need a good inverter to match you up with the grid's phase, and you'll wind up supplying power to the grid during your best generation hours (which happen to match up with their peak demand/most expensive hours), and taking it during their cheapest hours.
Most companies (possibly all) can bill you according to peak/off peak usage and contribution; so you can use as much as you want at night, and your daytime contribution will pay for it.
-Billy
Actually, a spending increase would definitely improve student performance. Spending more on education leads to more qualified teachers, better facilities, and smaller classes, all of which contribute to a better learning environment.
:-) -- but there are plenty of examples where that's exactly what happened, so your statement certainly should be amended to eliminate the word "definitely", and should include some discussion of how to solve the real problems, rather than just dumping more money onto them.
This fails to be backed by history. Spending more means more administration, more regulation, more teaching to standardised tests, and more lobbying to reduce those standards and remove legitimate competition.
Well, it doesn't ALWAYS mean that
I'm not against more money for education, of course; you ARE correct that it's needed. But it has to actually make it to the classes, and it has to be used wisely -- and right now, in most states of the US that's impossible.
-Billy
The problems arise when some countries have a slavish, not conicidentally religous fervor for "free markets" while others take a progressive attitude.
What's the problem? Those are the same, aren't they? Or are you redefining terms implicitly?
-Billy
And now fluorescent bulbs are becoming available for almost as cheap as a regular bulb, lasting longer, and using less electricity.
Yeah, companies are short-sighted -- but all it takes is ONE farsighted entrepreneur, and the short-sighted companies have to switch over or die. The customers can only buy what's available, but if you start providing what they want they'll pay you.
It's amazing how many people now are chanting, "you can't trust the free market!" This is based on truth, but is the exact opposite of the problem we're facing -- you're suggesting something very like pouring gasoline on a fire, or water on sodium (or both).
-Billy
Have you thought about that?
The problems are manifold. Do you get locked up because a person you had ordered from spammed? Do you get locked up if you ordered directly because of a spam? How do they prove that you ordered because of a spam?
And would this have the same success as the War on Drugs?
-Billy
1) The fail scenarios of space elevators are not very good. Think about the possible fail scenarios from the various areas: political, military, natural disaster, engineering. Consider the impacts and probabilities.
Cable break, you mean? Yup, that's bad. I don't think it's impossible to work around, but I agree that it has to be fully worked out before we implement. Good thing we have a few decades.
_Normal_ operation of a space elevator is clearly very safe, and therefore attractive. Catastrophic operation, however, desperately needs to be worked out.
2) Space elevators only get you up to geostationary (and maybe 2X), they don't get you much further than that.
Wrong. Once you're past geostationary, you're a slingshot, not just an elevator. You've got a LOT of options, anything in a plane with Earth's equator. And, of course, once you're well away from Earth you can use other options, like project Orion's nuke propulsion.
-Billy
Why would SCO's action cause everyone to stop using it?
Exactly my point. SCO's illegal actions can't stop _anyone_ from using Linux unless they can stop _everyone_ from using it.
You were also making a mistake when you said that SCO had to recall its product from its customers. Think about it -- who is SCO's customers? The answer isn't "everyone who's paid SCO money," because money isn't part of the violation. The answer is "everyone who's received illegal code from SCO." Guess what? If SCO's right, that's ALL of us.
Of course, like you, I don't think SCO's right. Well, I don't think it's substantially right; I think there's so much error, and the error goes both ways. If SCO survives this (and thanks to IBM, it won't), Linux will be freed, mostly by declarations of public domain and partly by removing SCO code.
-Billy
I admit that there's a theory about copyright law that claims that the law covers use. The problem is that if it's true, the GPL itself is invalid, or at least seriously lacking.
Either we ALL have to stop using Linux because SCO is using it to violate the law, or only SCO does. Which one makes sense to you?
-Billy
NO.
Read the GPL -- it specifically states that nothing can affect the right to use the software, only to distribute it.
Now, that might possibly NOT be what copyright law actually _means_ -- but that's what the people who use the GPL want their users to do. Thus, the people who contributed to the kernel explicitly allow use, regardless of other violations. (Not to mention that the GPL's drafters might have been right that copyright law DOES allow use without license.)
-Billy
Of course, THEN they get trod on by their own customers (what few they have left), who are suddenly without official support.
Correct -- I didn't say it would be easy, just simple. Every engineer knows that the two are opposites.
IIRC, SCO can't distribute Linux at all while violating the GPL like this.
Yup! All gone. No more customers.
I didn't mention that at least some of the customers might have grounds to sue for violation of contract, since SCO had to stop supporting them -- but I'm not sure what was in SCO's contracts. SCO would definitely be liable, since their actions led directly to them being unable to provide support.
SCO could very well be in a catch-22, unless their contracts with their customers are ALL completely free of continuing-support obligation. (And THAT would be a funny catch-22 itself, considering what they've said about indemnification!)
-Billy
so other people could sue those customers for using IP that they do not actually have a licence for.
No. The GPL is very explicit that it does not affect use; it allows it because copyright law allows it.
So SCO's customers don't need to know about the GPL, don't have to stop using, or anything else -- unless, of course, SCO rescinds their license to _its_ non-GPLed code.
But there's nothing in the GPL or copyright law that can force SCO to do _that_.
So no, SCO doesn't have to recall anything, only stop the violation.
-Billy
You may not oppress anyone, morally or otherwise. The Constitution grants power like that to "the people" as a whole under the formal arrangements of a government with limited powers.
If my society acts with my approval, I am morally responsible. Thus, I may be said to oppress anyone that my government oppresses with my approval. You can't hide behind "the people", and I refuse to.
Man, what is with people that they want to wield power over others? Is everybody power-hungry in this society?
Ad hominem -- and beside the point. I wasn't saying that, I was quoting you to demonstrate your error. You're using loaded terms in a very misleading way.
Every time you try to restrict corporate speech they will use that argument and they will win as long as they are considered persons.
You're going to lose if you keep that argument -- corporations ARE persons, and will always be. The question is whether artificial persons, AKA "merely legal persons" have the same rights as natural persons. THAT is an interesting and worthy question; the answer seems to be an obvious NO, but it's not clear to me exactly what rights they do and don't possess.
Mucking around with hair-splitting laws that attempt to target certain speech and not others will just muddy the waters and lead to endless litigation.
No, doing anything that costs someone else money will cause litigation. What do you expect?
There is absolutely NO reason why a law has to restrict ALL unwanted bad behavior at the same time. If it's okay to restrict ALL unwanted money-gathering calls, it's also okay to restrict a subset of them under the same conditions.
It would also be okay to require telemarketers to have licenses and meet certain requirements.
-Billy