Obviously, they're going to license McAfee's ASP business model patent. That way, they're not the ones preventing "innovation" - it's McAfee, who won't care one whit about the negative puiblicity, because MS will keep shoveling money at them to maintain an exclusibve license agreement.
Re:ThinkPads, Inspirons and Vaios All Work Quite W
on
Which Laptop To Buy?
·
· Score: 1
Well, I'm posting this from a Latitude CP running RedHat 7.1, so you have at least one example of it installing and running decently (stock RH laptop install - no custom kernel). I don't fiddle much with PCMCIA, though, so I can't really comment on how well it does (or doesn't) support that... as usual, YMMV.
Could be. Severe anticontamination restrictions make working with ebola and other level 4 biohazards extremely difficult. On the other hand, a "kinder" form of ebola - one that was far less deadly, but still produced the same reaction in a host - would probably be very useful when trying to study the course of the disease, identify transmission vectors, determine what treatments and/or vaccinations are possible, etc.
Sorry... no slight intended on those who do not hold any religious beliefs (much as I might disagree with you on that point.) My intent was a dig that those who don't hold "traditional" religious beliefs, but seem to have simply substituted unquestioning faith in a supernatural diety with a similar unquestioning faith in science. Since the most fundamental underpinning of science is the idea that anything you believe may be wrong, to me, having unquestioning faith in science in the same way one might have unquestioning faith in a diety seems innane.
This is just another example of them teaching something as fact and then finding out that they were wrong and throwing it away and replacing it with something else.
Umm... this pretty much is the definition of science. No scientist worth his or her salt would ever present a theory to you as fact. A fact is an observation - "When I let go of this ball, it falls to the earth." The theory is the attempt to explain the fact, and any scientist should tell you, quite cheerfully, that you can never prove a theory, you can only disprove it.
Now, if you want to disparage the educational system for forgetting to teach this important distinction; or the media for conveniently overlooking it in order to present a sensationalist story; or the socialists and athiests who use it in place of religion; or the politicos who use it to ram through purely political agendas like the Kyoto treaty... well, then you've got a case for being disgusted. Don't mistake the medium for the message, though.
Seeing as I feel the same way about Pittsburgh, I can sympathize... have you thought about northern California? From what I know, it's not nearly as insane as SoCal, and would still put you only a couple of hours from friends and family.
Professional organizations, not a union
on
Dial U for Union
·
· Score: 2
What the IT community needs is a professional organization like the ABA or AMA. There are several more specialized organizations, like the ACM, but not yet one that encompases all the various career flavors of the IT world.
So, if we're already voluntarily organized as professionals, why should we listen to these screaming socialists who want to unionize IT? The benefits we would receive in return for that are slim to none at this point; so the only reason to unionize seems to be the dark scowls and continual litany of "It may not always be like this..."
You know what? When it starts getting bad, and it looks like a union might help the situation, that's when IT workers will unionize. That's more or less the situation that's described in the article. Until such point, founding a union just is not worth the time, money, and effort to anyone except the union organizers.
Hard as it may be to believe, California is not the be-all end-all of the technology world. Just off the top of my head, you might consider Boston, Philadelphia, Pittsburgh, Baltimore, Washington DC, Atlanta, Chicago, Phoenix, Seattle...
But in the real world, the cat is out of the bag, systems they do not control exist, and there will be a way to crack everything.
Accurate, but you forgot the logical conclusion, which is the real reason that any sort of copy protection scheme is doomed:
It only has to be broken once.
Once anyone breaks the copy protection on a digital work, they can make the unprotected version of that work available to the world at large, for effectively zero cost and at almost zero risk. This is the real reason any sort of digital copy protection scheme is doomed; not because it's technically or politically difficult to implement, but because if it fails even once, it's effectively useless.
In other words, our expertise in this particular market is built right into the product. If someone else spent the thousands of hours required to reproduce this knowledge, we'd be out of business before Friday.
Can you separate the knowledge from the product? If so, you can possibly GPL the source for the product, make the data format for the knowledge base an open spec, and then license the data separately. Your customers (and anyone they passed the code on to) would have the code under the GPL, but the data that the code worked with would be owned by you and licensed to them for their use with a standard commercial license.
This is something that probably would not fly with the die-hard GPL crowd. <shrug> Despite that, it's one way to address your situation.
Actually, I think he was right. The key point is the first part of the GPL quote:
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
The case he presented was a non-GPL'd program that was not derived from his GPL'd code, but was capable of using his GPL'd code in a generic fashion (via a font selection dialog.) The GPL, in the above passage, seems to explictly recognize this case, as long as the non-GPL'd and the GPL'd products can "reasonably considered independent and separate works".
What's a reasonable way to consider two products independent and seperate works? In the font case, well... if there is nothing in the source code that references the font explicitly, I'd think that would be a good indication that the works are truly independent.
So, if the bloke who wrote the check printing program took the neccesary steps to ensure that it is a "independent and seperate work" from the GPL'd code, it seems that he wouldn't be required to distribute it under the GPL. Which brings up the second point:
...when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License...
If the first assertion is true - that is, the check writing program was an "independent and seperate work" that was not derived from the GPL'd code - then the distribution is not an issue, since the requirement to distribute under the GPL only applies if you distribute the non-GPl'd code "as part of a whole which is a work based on the Program". Since the whole of the work was not based on the GPL'd program, then it would seem that the GPL allows distribution of the GPL'd program in conjunction with the non-GPL'd program, without the requirement that "distribution of the whole" be under the terms of the GPL.
Final note: if the argument that a non-GPL'd program can be forced into being GPL'd by a plug-in or other non-essential component is accepted by a court, I would be very surprised... since it implies that someone other than a copyright holder can alter the license under which a work is distributed. Keep in mind that this is apparently not the situation with VirtuaDub and SloMedia... SloMedia has, by all accounts, failed to produce an "independent and seperate work", which probably puts them four-square in violation of the GPL.
The problem is that I am not being told the terms of the contract until after a transaction has taken place. In the US, at least, this is blatantly illegal... except that now, thanks to UCITA, it is specifically allowed in the case of shrink-wrapped software. More significantly, UCITA attempts to explicitly make the "if you are reading this contract, you have already agreed to abide by it" garbage that so many software licenses use legally binding.
I don't know about you, but I consider any law that twists legal principles established over the course of the last millena around 180 degrees to be "insidious".
Aladdin software had a policy regarding ghostscript: given the current version was N.x.x., then version (N-1).0.0 was released under a "free" license ("free" in quotes, because I'm not sure that OSI would agree that it's that kind of license.)
Given the typical commercial software release schedule (2-3 years to release version N+1), this type of arrangement seems to ensure that the software company can make money off of those who want and/or need the latest version. When the N+1 version comes out, release version N.0.0 under a GPL-like license that allowed anyone to (a) modify the source, (b) redistribute the modified source or binaries, but (c) forbid them from reselling the source or binaries.
The company can make money and recoup their investment off the latest release, phase out support for the previous release, or make a few more bucks by selling "officially supported" versions of the older software.
We know how much storage space this will require... likely the government does, as well. How long do you think it will be, really, before the EU, US, and other countries that sign on to these types of laws start providing government-run backup centers for this data... oh, no, not because they want centralized control of it; no, no, it'll just be more effecient that way, don't you know...
One of the requirements of XP is that the customer is on-site.
Understood... this seems to make XP unusable (or at least harder to use properly) for shrink-wrapped software, though, in that there is no single customer; unless you define the "customer" as the internal sales/marketing team. The overall emphasis of XP seems seems to be on consulting-type development, where a single client is interacting with a company to produce custom or customized software.
What the customer wants always changes over time.
Not always true. Where I'm working now, product requirements were laid out before design/development began, and we've managed to stick with them. We're developing a new product, though - one that we think will appeal to our target market for a number of reasons, but which hasn't existed up to this point. How do you ask a customer what they want when they don't even know they need your product?
To be honest, our initial product requirements (generated by business dev) and design goals (generated by development) included the ability to customize the product on a per-customer basis; when we get to that phase of development, perhaps the XP development model will be more effective.
Please check out XProgramming.com and ExtremeProgramming.org. You'll get a much better idea of what it's about from those sites than you will from me or from a short article.
Thanks for the references - I will take a look at them. Mind you, I'm not dismissing the methodology out of hand; from what I've already read, it seems to work extremely well under certain circumstances, when implemented properly. I question it as a cure-all solution for all possible development problems, though. In my mind, XP advocates would gain a lot more credibility if they could enumerate the situations in which XP was not a solution, and explain why, in those cases, XP was not applicable.
Customers are allowed to ask for anything they want. Programmers are allowed to force the customer to refine what they are asking for until the story can be estimated and tested.
If there's a point of failure in an XP implementation, this is it.
"Programmers? Talking to customers? That's what [sales|marketing|product development|customer relations] does!"
What's more likely... tht the VP of product development or customer relations will go along with a new programming methodology that reduces their importance in the company, or that any department that feels threatened by XP will do their best to scuttle the effort by injecting themselves into the process as "advisors" who promise features that are impossible to implement, ship dates that are impossible to meet, or anything else that might put those damned uppity programmers back in their 5x5 cubes where they belong?
In Xp, Business decisions are made by business people. What a novel concept:)
Except that many, many companies consider ship dates to be a business decision... because the customer is willing to pay more money to see it done more quickly. Many, many companies consider feature lists to be a business decision... because the customer is willing to pay more money to see what they consider essential features implemented. Many, many companies consider the quality of the code a business decision... because the customer will then spend 10x as much money over the next ten years, paying for bug fixes, support, and incremental upgrades that add the feature that was supposed to have been put in 5 releases ago.
In short, many, many companies look upon programmers not as valuable employees, but interchangable assets that can be used to leverage money out of paying customers. There are companies that are different, but they are few and far between... and I think they would tend to be companies that have business, sales, or development models that make XP harder to implement for technical (as opposed to political) reasons.
You haven't read what XP is, then. It's a way of developing the software that the customer wants.
So, you're saying that in an instance where you are unsure of who your customer is, or what they want, then XP doesn't make sense, and traditional methodologies are more effective?
What about instances where what the customer wants changes over time (new business strategy; new tactical goals; change in company emphasis) - how well does XP deal with those cases?
What about instances where the customer changes over time - company X gets bought out by company Y, or (if you're a shrink-wrapped software shop) it becomes apparent that your marketing department fsck'ed up and you target market is not greenhouse managers, but home gardeners?
XP looks interesting, and in a lot of ways, appeals to me. I don't think that it sufficiently addresses some of the edge cases in project management, though; and in the past ten years, every project I've worked on has had some edge case behavior. Inevitably, XP seems to deal with this by saying "Well, those aren't normal software development projects"... when studies by Yourdon and others seem to indicate that they are (take a look at Death March).
Looser pays winner's court cost? No, thanks. Big Hairy Corp would probably consider it a small investment to spend that additional 100K intimidating you by keeping you in court for a year or two. Yeah, you get your money back... but you've lost time, sleep, and gained nothing but stress over it.
Also... heaven forbid that you are the one to bring suit against BHCorp... you had better be damn sure you will win, because you sure as hell can't afford to pay their legal bills.
"Looser pays" only works if the two litigants have roughly the same assets. Once you get into a huge disparity, the side with the most money wins, because they cn afford to litigate in order to gain advantage, whether or not they win.
Now, if the proposal was "looser pays winners court costs, up to the amount that the looser spent in court", then you've got something that might work. If BHCorp spends $10,000,000 suing me, and I spend $1,000 defending myself and loose... well, I owe my lawyer $1,000, and BHCorp $1,000 towards their court costs. If I win, they have to shell out an additional $1000 to cover my court costs.
Overall, I think this is a better solution... the more you spend to try and win a case, the more you risk loosing.
Yah... I've looked at Junkbuster in the past; all that's really needed is the ability to fetch that list from a remote location. I started to look into it, but life (in the guise of my newly arrived daughter) intervened:-)
If the filter was a local process/proxy - which is what was proposed - there's a small chance of the internet "grinding to a halt", as you put it.
And, quite frankly, I don't routinely visit half the internet; I doubt many other people do, either. There's a small subset of sites that I'm willing to trust to deliver up what I consider reasonable content in various areas. Couple this with domain/IP filtering (as opposed to URL filtering), and I think it would be a reasonable trade off between speed and functionality.
Finally... when I said "opt-out by default", I was referring to a default installation of the filter software (my apologies, again, for being unclear on the topic.) I think software like this should be installed in "secure" mode, and users should be able to loosen restrictions as they run into them, instead of the opposite.
I've thought about this and discussed it in the past. In order for this sort of thing to work, I think you need to make a couple of assumptions:
The data format for filter lists must be standardized and flexible enough to permit anyone to easily assemble and disseminate a list. A simple text file would probably do, as that can be "published" via HTTP or downloaded and "installed" by dropping it into a directory.
Another data format item... I'd think this is the sort of thing that XML would be overkill for, but supporting an XML format in addtiion to a plain-text format would allow for greater flexibility. For example, a list of sites could be broken down by general content, publisher, etc., in order to allow additional filtering (allow "Child-Friendly" sites, except for those run by The Mouse).
Filtering is opt-out by default. By this, I mean that if a site does not appear in any of your subscribed lists, it gets blocked. Unfortunately, this is the only real way (short of analyzing content in real-time) to ensure that various types of web spammers, particularly pornographers, can't fo an end-run around the filtering. Note that I don't think this should be the only mode of operation; just that the default settings should be "disallow access unless approved by me or someone I have decided to trust".
Multiple subscriptions are going to be the default. While I'd be quite happy suscribing to a list of Christian-friendly sites, it's unlikely that other interests of mine (/., for example) would end up on those lists. This could certainly be handled in part by a "local" list.
Adding new sites to the "local" list should be trivial for someone who has permission to do so. Editing a text file and restarting your browser doesn't cut it; seeing a "Access to this page has been blocked... add it to the local list?" in your browser would.
Whatever proxy is handling the filtering should be able to handle differing collections of access lists based on user. If Junior logs in, I want to ban potentially dangerous sites. On the other hand, I've got to deal with those buggers daily, so when I'm logged in, I should be able to access them.
Comments? Or has someone already gone and registered a Source Forge project for this?
Likewise. Company I used to work for did something very similar, using a CRC calculated using the text of a web page to determine web page "identity". I would be surprised if the Lycos (or Altavista, or Webcrawler, or Hotbot...) spiders didn't do something very similar.
Which brings up an interesting question - if, by 1997, there were enough companies implementing this sort of "technology" already, then can't it be argued that the Pumatech patent is obviously invalid because at the time they applied for it, it was already in use by multiple companies... which seems to me to indicate that their "innovative" technology is "obvious to a practioner skilled in the arts".
The fact of the matter is their is NO LAW requiring someone to apply for a Social Security account.
You're absolutely right. However... I never applied for a SNN; my parents did that for me (in fact, it may have even been done automatically by the hospital, for all I know.) Now that I'm "in the system", there's probably no way in hell that I'll ever get out of it. Even if I can get my SSN revoked, there's still 30+ years worth of information on me that the government has available.
Slashdot Mirror
Obviously, they're going to license McAfee's ASP business model patent. That way, they're not the ones preventing "innovation" - it's McAfee, who won't care one whit about the negative puiblicity, because MS will keep shoveling money at them to maintain an exclusibve license agreement.
Well, I'm posting this from a Latitude CP running RedHat 7.1, so you have at least one example of it installing and running decently (stock RH laptop install - no custom kernel). I don't fiddle much with PCMCIA, though, so I can't really comment on how well it does (or doesn't) support that... as usual, YMMV.
Could be. Severe anticontamination restrictions make working with ebola and other level 4 biohazards extremely difficult. On the other hand, a "kinder" form of ebola - one that was far less deadly, but still produced the same reaction in a host - would probably be very useful when trying to study the course of the disease, identify transmission vectors, determine what treatments and/or vaccinations are possible, etc.
Heh. Of course, not everyone in the soft drink industry cares about their profit margin...
Sorry... no slight intended on those who do not hold any religious beliefs (much as I might disagree with you on that point.) My intent was a dig that those who don't hold "traditional" religious beliefs, but seem to have simply substituted unquestioning faith in a supernatural diety with a similar unquestioning faith in science. Since the most fundamental underpinning of science is the idea that anything you believe may be wrong, to me, having unquestioning faith in science in the same way one might have unquestioning faith in a diety seems innane.
Umm... this pretty much is the definition of science. No scientist worth his or her salt would ever present a theory to you as fact. A fact is an observation - "When I let go of this ball, it falls to the earth." The theory is the attempt to explain the fact, and any scientist should tell you, quite cheerfully, that you can never prove a theory, you can only disprove it.
Now, if you want to disparage the educational system for forgetting to teach this important distinction; or the media for conveniently overlooking it in order to present a sensationalist story; or the socialists and athiests who use it in place of religion; or the politicos who use it to ram through purely political agendas like the Kyoto treaty... well, then you've got a case for being disgusted. Don't mistake the medium for the message, though.
Seeing as I feel the same way about Pittsburgh, I can sympathize... have you thought about northern California? From what I know, it's not nearly as insane as SoCal, and would still put you only a couple of hours from friends and family.
What the IT community needs is a professional organization like the ABA or AMA. There are several more specialized organizations, like the ACM, but not yet one that encompases all the various career flavors of the IT world.
So, if we're already voluntarily organized as professionals, why should we listen to these screaming socialists who want to unionize IT? The benefits we would receive in return for that are slim to none at this point; so the only reason to unionize seems to be the dark scowls and continual litany of "It may not always be like this..."
You know what? When it starts getting bad, and it looks like a union might help the situation, that's when IT workers will unionize. That's more or less the situation that's described in the article. Until such point, founding a union just is not worth the time, money, and effort to anyone except the union organizers.
Folks, if it ain't broke, don't fix it.
Leave.
Hard as it may be to believe, California is not the be-all end-all of the technology world. Just off the top of my head, you might consider Boston, Philadelphia, Pittsburgh, Baltimore, Washington DC, Atlanta, Chicago, Phoenix, Seattle...
Accurate, but you forgot the logical conclusion, which is the real reason that any sort of copy protection scheme is doomed:
Once anyone breaks the copy protection on a digital work, they can make the unprotected version of that work available to the world at large, for effectively zero cost and at almost zero risk. This is the real reason any sort of digital copy protection scheme is doomed; not because it's technically or politically difficult to implement, but because if it fails even once, it's effectively useless.
Can you separate the knowledge from the product? If so, you can possibly GPL the source for the product, make the data format for the knowledge base an open spec, and then license the data separately. Your customers (and anyone they passed the code on to) would have the code under the GPL, but the data that the code worked with would be owned by you and licensed to them for their use with a standard commercial license.
This is something that probably would not fly with the die-hard GPL crowd. <shrug> Despite that, it's one way to address your situation.
Actually, I think he was right. The key point is the first part of the GPL quote:
The case he presented was a non-GPL'd program that was not derived from his GPL'd code, but was capable of using his GPL'd code in a generic fashion (via a font selection dialog.) The GPL, in the above passage, seems to explictly recognize this case, as long as the non-GPL'd and the GPL'd products can "reasonably considered independent and separate works".
What's a reasonable way to consider two products independent and seperate works? In the font case, well... if there is nothing in the source code that references the font explicitly, I'd think that would be a good indication that the works are truly independent.
So, if the bloke who wrote the check printing program took the neccesary steps to ensure that it is a "independent and seperate work" from the GPL'd code, it seems that he wouldn't be required to distribute it under the GPL. Which brings up the second point:
If the first assertion is true - that is, the check writing program was an "independent and seperate work" that was not derived from the GPL'd code - then the distribution is not an issue, since the requirement to distribute under the GPL only applies if you distribute the non-GPl'd code "as part of a whole which is a work based on the Program". Since the whole of the work was not based on the GPL'd program, then it would seem that the GPL allows distribution of the GPL'd program in conjunction with the non-GPL'd program, without the requirement that "distribution of the whole" be under the terms of the GPL.
Final note: if the argument that a non-GPL'd program can be forced into being GPL'd by a plug-in or other non-essential component is accepted by a court, I would be very surprised... since it implies that someone other than a copyright holder can alter the license under which a work is distributed. Keep in mind that this is apparently not the situation with VirtuaDub and SloMedia... SloMedia has, by all accounts, failed to produce an "independent and seperate work", which probably puts them four-square in violation of the GPL.
The problem is that I am not being told the terms of the contract until after a transaction has taken place. In the US, at least, this is blatantly illegal... except that now, thanks to UCITA, it is specifically allowed in the case of shrink-wrapped software. More significantly, UCITA attempts to explicitly make the "if you are reading this contract, you have already agreed to abide by it" garbage that so many software licenses use legally binding.
I don't know about you, but I consider any law that twists legal principles established over the course of the last millena around 180 degrees to be "insidious".
Aladdin software had a policy regarding ghostscript: given the current version was N.x.x., then version (N-1).0.0 was released under a "free" license ("free" in quotes, because I'm not sure that OSI would agree that it's that kind of license.)
Given the typical commercial software release schedule (2-3 years to release version N+1), this type of arrangement seems to ensure that the software company can make money off of those who want and/or need the latest version. When the N+1 version comes out, release version N.0.0 under a GPL-like license that allowed anyone to (a) modify the source, (b) redistribute the modified source or binaries, but (c) forbid them from reselling the source or binaries.
The company can make money and recoup their investment off the latest release, phase out support for the previous release, or make a few more bucks by selling "officially supported" versions of the older software.
We know how much storage space this will require... likely the government does, as well. How long do you think it will be, really, before the EU, US, and other countries that sign on to these types of laws start providing government-run backup centers for this data... oh, no, not because they want centralized control of it; no, no, it'll just be more effecient that way, don't you know...
Sigh. Right after submitting, I thought, "PMRC? What? You dolt! It's PRC! PMRC was Tipper's stupid music censorship effort! Augh!""
Ah, well. Hopefully the sarcasm stands even with the error. You did notice it was sarcasm, right? You didn't? Oh, dear. Maybe I was too subtle...
Understood... this seems to make XP unusable (or at least harder to use properly) for shrink-wrapped software, though, in that there is no single customer; unless you define the "customer" as the internal sales/marketing team. The overall emphasis of XP seems seems to be on consulting-type development, where a single client is interacting with a company to produce custom or customized software.
Not always true. Where I'm working now, product requirements were laid out before design/development began, and we've managed to stick with them. We're developing a new product, though - one that we think will appeal to our target market for a number of reasons, but which hasn't existed up to this point. How do you ask a customer what they want when they don't even know they need your product?
To be honest, our initial product requirements (generated by business dev) and design goals (generated by development) included the ability to customize the product on a per-customer basis; when we get to that phase of development, perhaps the XP development model will be more effective.
Thanks for the references - I will take a look at them. Mind you, I'm not dismissing the methodology out of hand; from what I've already read, it seems to work extremely well under certain circumstances, when implemented properly. I question it as a cure-all solution for all possible development problems, though. In my mind, XP advocates would gain a lot more credibility if they could enumerate the situations in which XP was not a solution, and explain why, in those cases, XP was not applicable.
If there's a point of failure in an XP implementation, this is it.
What's more likely... tht the VP of product development or customer relations will go along with a new programming methodology that reduces their importance in the company, or that any department that feels threatened by XP will do their best to scuttle the effort by injecting themselves into the process as "advisors" who promise features that are impossible to implement, ship dates that are impossible to meet, or anything else that might put those damned uppity programmers back in their 5x5 cubes where they belong?
Except that many, many companies consider ship dates to be a business decision... because the customer is willing to pay more money to see it done more quickly. Many, many companies consider feature lists to be a business decision... because the customer is willing to pay more money to see what they consider essential features implemented. Many, many companies consider the quality of the code a business decision... because the customer will then spend 10x as much money over the next ten years, paying for bug fixes, support, and incremental upgrades that add the feature that was supposed to have been put in 5 releases ago.
In short, many, many companies look upon programmers not as valuable employees, but interchangable assets that can be used to leverage money out of paying customers. There are companies that are different, but they are few and far between... and I think they would tend to be companies that have business, sales, or development models that make XP harder to implement for technical (as opposed to political) reasons.
So, you're saying that in an instance where you are unsure of who your customer is, or what they want, then XP doesn't make sense, and traditional methodologies are more effective?
What about instances where what the customer wants changes over time (new business strategy; new tactical goals; change in company emphasis) - how well does XP deal with those cases?
What about instances where the customer changes over time - company X gets bought out by company Y, or (if you're a shrink-wrapped software shop) it becomes apparent that your marketing department fsck'ed up and you target market is not greenhouse managers, but home gardeners?
XP looks interesting, and in a lot of ways, appeals to me. I don't think that it sufficiently addresses some of the edge cases in project management, though; and in the past ten years, every project I've worked on has had some edge case behavior. Inevitably, XP seems to deal with this by saying "Well, those aren't normal software development projects"... when studies by Yourdon and others seem to indicate that they are (take a look at Death March).
Looser pays winner's court cost? No, thanks. Big Hairy Corp would probably consider it a small investment to spend that additional 100K intimidating you by keeping you in court for a year or two. Yeah, you get your money back... but you've lost time, sleep, and gained nothing but stress over it.
Also... heaven forbid that you are the one to bring suit against BHCorp... you had better be damn sure you will win, because you sure as hell can't afford to pay their legal bills.
"Looser pays" only works if the two litigants have roughly the same assets. Once you get into a huge disparity, the side with the most money wins, because they cn afford to litigate in order to gain advantage, whether or not they win.
Now, if the proposal was "looser pays winners court costs, up to the amount that the looser spent in court", then you've got something that might work. If BHCorp spends $10,000,000 suing me, and I spend $1,000 defending myself and loose... well, I owe my lawyer $1,000, and BHCorp $1,000 towards their court costs. If I win, they have to shell out an additional $1000 to cover my court costs.
Overall, I think this is a better solution... the more you spend to try and win a case, the more you risk loosing.
Yah... I've looked at Junkbuster in the past; all that's really needed is the ability to fetch that list from a remote location. I started to look into it, but life (in the guise of my newly arrived daughter) intervened :-)
If the filter was a local process/proxy - which is what was proposed - there's a small chance of the internet "grinding to a halt", as you put it.
And, quite frankly, I don't routinely visit half the internet; I doubt many other people do, either. There's a small subset of sites that I'm willing to trust to deliver up what I consider reasonable content in various areas. Couple this with domain/IP filtering (as opposed to URL filtering), and I think it would be a reasonable trade off between speed and functionality.
Finally... when I said "opt-out by default", I was referring to a default installation of the filter software (my apologies, again, for being unclear on the topic.) I think software like this should be installed in "secure" mode, and users should be able to loosen restrictions as they run into them, instead of the opposite.
I've thought about this and discussed it in the past. In order for this sort of thing to work, I think you need to make a couple of assumptions:
Comments? Or has someone already gone and registered a Source Forge project for this?
Likewise. Company I used to work for did something very similar, using a CRC calculated using the text of a web page to determine web page "identity". I would be surprised if the Lycos (or Altavista, or Webcrawler, or Hotbot...) spiders didn't do something very similar.
Which brings up an interesting question - if, by 1997, there were enough companies implementing this sort of "technology" already, then can't it be argued that the Pumatech patent is obviously invalid because at the time they applied for it, it was already in use by multiple companies... which seems to me to indicate that their "innovative" technology is "obvious to a practioner skilled in the arts".
You're absolutely right. However... I never applied for a SNN; my parents did that for me (in fact, it may have even been done automatically by the hospital, for all I know.) Now that I'm "in the system", there's probably no way in hell that I'll ever get out of it. Even if I can get my SSN revoked, there's still 30+ years worth of information on me that the government has available.