I wonder what those "investigators" would do faced with a system where the browser was set to clear cookies on exit, clear the history on exit, and either clear the cache or not use a cache at all, where you can't get a desktop or a command prompt at all without having a valid username and password, and where the filesystem isn't supported by Windows. If they can't deal with simple things like this, how are they going to deal with criminals who know what they're doing and use stuff like encrypted filesystems and disk-wiping and free-space-zeroing programs?
Your first paragraph's one of the fallacies of the current system: not every idea someone comes up with is patentable. The Flowbee's a good example of that. Certainly it's never been thought of before, but once someone thinks "I wish I had a way of getting that hair collected before it falls on the floor..." and starts to thinking about the problem at all it doesn't take any real insight to come up with the Flowbee or something very much like it. There's a distinction between something nobody's thought of yet and something novel and non-obvious enough to be deserving of patent protection. Note that there's not unlimited time involved. Something that someone in the field can come up with once they've decided to look at it, but that'll take them several weeks or several months to work out once they've got the idea, wouldn't invalidate the patent because they couldn't come up with a description of it within the 5-day timeframe.
As for the second paragraph, I'd leave that up to the applicant.:) They get to make a sworn statement as to whether that item in their opinion infringes on their patent or not. If they say yes, then it's considered "close enough" to invalidate the patent. If they say no, then their patent stands but their sworn statement blocks them from ever making an infringement claim against that item. As for the group, I wouldn't make explicit groups at all. I'd just pick from existing databases of people working in specific fields. For example, if someone applies for a patent on a new type of IC-chip manufacturing technology, I'd call up the IEEE and ask them to put me in touch with a dozen members who specialize in IC-chip manufacturing. If someone applies for a patent on a new way to unclog drains, I'd pick a random city, open the Yellow Pages for it up to Plumbers and call half-a-dozen places listed and ask if any of their plumbers would be interested in vetting something. Spread it around, and be prepared to get some more names if someone says they don't have the free time, and it should work acceptably (ie. better than the current system appears to).
To make it fair. The idea isn't to filter out everything, it's to filter out those things that're so obvious most of the people in the field would think of them immediately. If you ask a couple of million people, one of them may stumble on even the most unobvious methods by sheer accident. If you ask a half-dozen or dozen and they come up with it, though, it's probably well-known or at least an obvious idea once someone turns their attention to the problem. There's a time limit for the same reason. Given enough time an expert can eventually come up with even highly unobvious methods, we're looking for the ones he'll come up with without having to puzzle them out.
It's telling that Microsoft were the ones who went to eWeek with the story, without consulting Cohen or asking for his OK on telling the world about the meeting. Since Microsoft were also the ones asking for the meeting in the first place, one has to wonder whether it was done solely to be able to place a piece like this?
Actually one doesn't have to wonder, knowing Redmond.
I'll take first-to-file with one condition: if anything the patentholder claims infringes on their patent can be shown to have been described either to patentholder or in public prior to the patent's filing date, the patent's automatically invalidated. If the patent application disclosed the prior description, only the claims alleged to have been infringed are invalidated. If the patent application failed to disclose the prior description, it's considered evidence of bad faith and the patent's invalidated in it's entirety (but remains on the record and counts as description for purposes of other patents).
I'd also add a patent filter process. The end result (not the methods) described in the patent is presented to a randomly-selected half-dozen or so people competent in the field. They get 5 working days to come up with ways to achieve that end result. If any of them come up with the method described in the patent, without having seen the patent's description of the method, the patent is denied on the grounds of obviousness.
My problem with DRM isn't the concept itself, it's the one-sidedness of current implementations: the existing DRM systems enforce the rights the media companies want enforced, but they don't enforce the rights copyright law grants to copy-owners. An open DRM system at least offers the ability to lay down within the system all rights including the ones copyright law grants that the media companies don't like. If we lay down the standard with reference to relevant statute and case law, we can change the playing field so the media companies have to argue why a DRM system shouldn't comply with the law when they object to things like time-shifting and personal-copy rights.
There's another issue of licensing to consider when figuring TCO, and that's your upgrade path and timing in the future. Microsoft has, the last 2 times they went to update their licensing terms, tried as hard as they could to move those terms to an annual-subscription basis, and they don't seem to have given up on the idea. From their standpoint it's a good one, it guarantees their cash flow. If you buy Windows under those terms (and if MS has any say in it you wouldn't have a choice), come time to renew your licenses you might end up in a bind:
Upgrading to the most-current version of Windows would be expensive and inconvenient in terms of hardware and third-party-software upgrades, and right now your business is better served by spending that money and effort elsewhere.
Microsoft won't accept payment and renew your licenses, because they've end-of-lifed that version of Windows and don't sell annual licenses for it anymore.
If the licenses aren't renewed, all of your machines stop working completely the day after the licenses expire, shutting your business down completely.
Considering that Microsoft has tried to make this world a reality in the last 2 iterations of their licensing revisions, and that the majority of the corporate world is using a version of Windows that, while only 1 version behind the most recent stable version, is slated to be end-of-lifed at the end of this year, I think the above scenario has to be taken seriously.
With open-source systems, at least you have options here. Your support contracts may end, but you never have to worry about the actual systems ceasing to work because of that. If you absolutely need support, you can buy it from another party if your original vendor won't give it to you. And in the absolute worst case you can hire some geeks to maintain it in-house. You can decide for yourself, based on your business needs, when and how to upgrade your systems, without any real fear that your vendor will force an upgrade on you at effective gun-point.
Take a look at the bottom-right corner. If a site's tried to set unallowed cookies, or tried to create a blocked pop-up, there'll be one or more icons down there. Clicking on the icons will bring up the appropriate dialogs to let you configure things.
One thing the "cookies aren't usually deleted" crowd tends to gloss over is the ability of browsers to force cookies to be session-only, or to delete cookies when the browser closes. People set up for this appear to all the stats engines as accepting cookies, but cookies set on them don't persist the way the stats engines expect them to. I think they gloss this over because it's all but impossible for a stats engine to detect this situation and count it.
The best estimates I can come up with are that something like 5-6% of all users have their browsers set to force even cookies from the site's domain to session-only (or discard them upon browser close), and something like an additional 16-17% either block third-party cookies completely or discard them at the end of a browsing session. And those percentages have been trending upwards over time.
It'll be worse, the retailers will get in on it. They'll be getting all sorts of returns from people who don't have an Internet connection. Parents whose player doesn't work after little Johnny unbeknownst to them tried to play a disc his friend at school gave him. People whose player got "self-destructed" because somebody at a content provider mis-keyed a serial number. And people won't be happy about having to pay restocking or repair fees when they didn't do anything to break the player. A few consumer complaints later, Blu-Ray players will be anathema to retailers who can't afford to eat the cost of all those returns.
One program I've had luck with is the HTML Tidy program at http://www.w3.org/People/Raggett/tidy/. It seems to clean up code (particularly from Word) quite a bit.
First, ignore all the per-capita methods. They won't work.
Now, take your lists of what you need to spend and what you want to spend. Lay out the items, give each one a priority ranging from "must have" to "would be nice". Provide a justification for each one and for the priority you gave it. Give all justifications, not just the best one, with examples from reality (eg. the justification for the anti-virus software might make reference to actual virus infestations in the company in the previous year and how much they cost in money, time and resources). Be sure to account for recurring costs in future years (eg. the service contracts on equipment, anti-virus update services, etc.).
Once you've got your list, sit down with the Finance guys and figure out how far down the list the business can afford to go.
Realistic budgets aren't based on per-capita expenditures or percentages of revenues or profits, they're based on what the business actually needs to spend to stay in business.
There already are things to do this. Most distributions come with a graphical system-configuration tool that does exactly what you describe for the major packages. There's no real need for another layer on top of that for remote management, any X11 app is automatically remoteable (X11 beneath the GUI simply doesn't distinguish between local and remote displays, so anything you can run locally you can run remotely).
Of course, I don't like the GUI tools for one basic reason: history. Not my history, the config file's history. If I maintain my config files directly, I can keep them in CVS and maintain a history of exactly what changed when in them. Comes in real handy when something suddenly breaks and I can go back and a) check whether the files being used match the last known versions I have, and b) review the exact sequence of changes to see what could have caused the problem. I haven't seen any management tools in Windows that offer this form of change history to me. If I'm managing multiple servers, I maintain the files in CVS on a central machine, make my changes there, vet them, then use rsync or rdist to propagage the changes out to the machines that need them and do any command sequences that need done before or after applying the change.
A final advantage of text files as the ultimate configuration source: I can edit text files just about anywhere. I don't always have access to a Windows machine, nor do I always have access to one with an open enough firewall to let me connect via the management protocols I need. I've rarely found anywhere where I couldn't SSH where I needed to, though, and if I've got a terminal window I can call up vi and edit those nasty, primitive text files from my cel phone if I have to. It's good insurance knowing that your admins can do anything they need to do any time they need to do it without having to worry about setting up a VPN or reconfiguring a firewall to allow the needed protocols through (or worse yet, not being able to do those things because the only network they've got access to doesn't allow taht).
First, he talks about demands for fixes within 15-day or 30-day periods. Sorry, wrong. The behavior that causes so many people to push for full disclosure is vendors not even
As for tying seceurity releases and disclosure to financial quarters, sorry but no. That's not the vendor's call to make, it's mine. If the problem's severe enough I may have to overrule procedure and test and implement the fix regardless. But the vendor can't decide that for me, and I can't decide it for myself if the vendor's not telling me "for my convenience".
I know Walmart (blechptooey) has a solution to a lot of this. When they ring up your sale, the receipt goes into their computer system. When you go to return an item they don't trust the paper receipt you've got, they pull up the record from the computer. Then they update the record to reflect the return, and print you a new receipt if you need one (eg. you haven't returned everything on the receipt). If you try to reuse the receipt to return the same thing again, the electronic record will trip you up. As far as I can tell, they update the records in real-time so even if you immediately to go another store they're be able to see your return and will refuse to take the second try.
As for the problem of people substituting cheaper items in the box and getting money/credit for the more expensive one, there's another simple solution to that: hire clerks who know your products. Of course you probably won't be able to get them for minimum wage, but them's the breaks. The store'll just have to decide which costs them less: paying higher wages or eating losses due to lower-quality employees.
I think the prevalence of the problem goes back to store policies at least in part. More and more often, stores have implemented draconian policies on returns. Often they charge 10-20% restocking fees even when the merchandise genuinely and obvious was defective when bought. That contributes a lot to customers deciding "Well, they're screwing me over every change they get, why shouldn't I play by their rules?".
What if you tell me that a particular task takes 80 hours, but in reality it takes you only 20? I have no way of knowing that I'm wasting 60 hours!
You're trusting me to create the software that's going to determine whether your business succeeds or fails, but you don't trust me to be honest with you about schedules? I think you've got a more fundamental problem, then. Either you can't trust me period, or your expectations on schedules are out of line with reality and nothing can be done until you correct your expectations. Oddly, I've found the latter to be far more often the case (this was in fact the primary reason I changed jobs earlier this year).
If I have you in a cubicle, I can look over your shoulder and make certain that you are working, I can monitor your browsing, check for personal emails, etc - in other words, I can track how you're spending your time and if you're ripping me off I'll know it.
And why do you need to do this? You hired me to do a job. Either I'm turning in the results on time and to spec or I'm not. If I'm not, you might need to watch me closer to figure out why. But if I'm finishing my projects on time and my schedules are reasonable, why should you need to confirm that I'm doing what I'm obviously doing?
I think the lack of maturity here isn't on the developers' side. I've found most commonly that managers lack the maturity to trust highly-paid professionals to simply do their job unless and until there's evidence they aren't.
I need specific details for a couple of things. Firstly is to evaluate whether this is a real problem. A lot of problems are highly configuration-specific, and I need to test not just whether it's a problem in the general case but also whether it's a problem that I can be bit by given the configuration of my particular network. In addition, I need to be able to test any fixes Cisco might put out. Vendors have had histories of putting out "fixes" just to say they have, but the fix only deals with the one particular example and leaves everyone exposed to even trivial variations on the original attack (eg. dealing with Code Red by blocking the one specific URL string used, leaving you vulnerable to Code Red with one character in the padding changed).
I keep seeing how vendors react, and it's always "the researchers need to compromise". The vendor's position is always "no release of any information period". We gave them right of first notice, we gave them time to fix the problem before details were released, and after that they still seem to want more compromises. I've become convinced that they won't stop compromising short of their own position, and that as long as that's the case the only response can be no compromise at all.
I wonder what would happen if a large user of network equipment, who depends on that equipment operating properly to stay in business, filed against Cisco on this? After all, they know how dependent others are on their equipment, they knew their errors in coding had put those other people at risk, and they not only didn't do anything about the situation they actively tried to block information from the people who'd be harmed. Seems to me that if a dangerous situation existed and the person responsible for it actively tried to keep the people endangered from finding out about it, that's usually grounds for additional penalties against the responsible party.
On the other hand, knowing about the problem I can now take steps to mitigate it by, for example, making sure my back-up routers are not made by Cisco, or by replacing vulnerable equipment with other types that aren't vulnerable. Of course this would hurt Cisco, which is the reason IMHO they tried to shut the guy up.
Do remember that there's limits on non-compete clauses. They apply if the employee quits or was dismissed for cause. They do not apply if the company dismissed the employee for no cause or if the employee is otherwise not responsible for the dismissal. I recall one of the claims Mr. Lee made was that Microsoft wasn't assigning him work and providing him opportunities appropriate to his skill. That reminds me of the seminal "constructive dismissal" case, and if Mr. Lee can successfully make that argument before the judge then Microsoft is out of luck (and may be liable to Google for interfering).
Only problem is, if you wait until they ask it's going to take you time (and lots of it) to re-design and recode everything. They're likely motivated by something major, eg. possible legal liability if they continue to allow known security problems, and you're then going to get back from them "Well, we can't wait N months for you to convert. Your competitors already support non-IE browsers, we're going to them.".
Then they wouldn't need the databases the EFF found linking the serial number of the printer to the identity of the person who bought it, would they? The existence of those databases seems to imply that the government at least planned to be able to track a document back to the person who printed it (or at least owned the printer used).
GMT's a good thing for computers, a bad thing for humans. The whole idea of timezones in the first place is to put noon on the clock at roughly the same time as noon by the sun. DST is an annoyance because it shifts things around inconsistently without actually improving sync between clock and sun.
If you've sense you get the offer and acceptance in writing and signed, with a listing of exactly what conditions still need to be satisfied before your first day of work, before you hand in your resignation at your old job. And make sure any conditions listed (eg. passing a drug test, etc.) are acceptable and don't have loopholes (eg. no generic "pass a background check" language, have them spell out exactly what sorts of things would disqualify you if they turned up in your background check). Then if they try the "You need to agree to these new terms, they're standard for all employees, if you don't we can't hire you." line, you can say "Sorry, you already hired me. See, here's everything all written out with signatures from your company's representatives, and that agreement isn't mentioned anywhere as a condition of employment.". They can still refuse to pay you, but they'll have a hard time in court getting past those signed documents.
I get riled up over the inability of the telemarketers to accept it when I say "Thanks, not interested, take me off your list.". After telling the same company that 18 times in one month, it gets a tad old.
Slashdot Mirror
I wonder what those "investigators" would do faced with a system where the browser was set to clear cookies on exit, clear the history on exit, and either clear the cache or not use a cache at all, where you can't get a desktop or a command prompt at all without having a valid username and password, and where the filesystem isn't supported by Windows. If they can't deal with simple things like this, how are they going to deal with criminals who know what they're doing and use stuff like encrypted filesystems and disk-wiping and free-space-zeroing programs?
Your first paragraph's one of the fallacies of the current system: not every idea someone comes up with is patentable. The Flowbee's a good example of that. Certainly it's never been thought of before, but once someone thinks "I wish I had a way of getting that hair collected before it falls on the floor..." and starts to thinking about the problem at all it doesn't take any real insight to come up with the Flowbee or something very much like it. There's a distinction between something nobody's thought of yet and something novel and non-obvious enough to be deserving of patent protection. Note that there's not unlimited time involved. Something that someone in the field can come up with once they've decided to look at it, but that'll take them several weeks or several months to work out once they've got the idea, wouldn't invalidate the patent because they couldn't come up with a description of it within the 5-day timeframe.
As for the second paragraph, I'd leave that up to the applicant. :) They get to make a sworn statement as to whether that item in their opinion infringes on their patent or not. If they say yes, then it's considered "close enough" to invalidate the patent. If they say no, then their patent stands but their sworn statement blocks them from ever making an infringement claim against that item. As for the group, I wouldn't make explicit groups at all. I'd just pick from existing databases of people working in specific fields. For example, if someone applies for a patent on a new type of IC-chip manufacturing technology, I'd call up the IEEE and ask them to put me in touch with a dozen members who specialize in IC-chip manufacturing. If someone applies for a patent on a new way to unclog drains, I'd pick a random city, open the Yellow Pages for it up to Plumbers and call half-a-dozen places listed and ask if any of their plumbers would be interested in vetting something. Spread it around, and be prepared to get some more names if someone says they don't have the free time, and it should work acceptably (ie. better than the current system appears to).
To make it fair. The idea isn't to filter out everything, it's to filter out those things that're so obvious most of the people in the field would think of them immediately. If you ask a couple of million people, one of them may stumble on even the most unobvious methods by sheer accident. If you ask a half-dozen or dozen and they come up with it, though, it's probably well-known or at least an obvious idea once someone turns their attention to the problem. There's a time limit for the same reason. Given enough time an expert can eventually come up with even highly unobvious methods, we're looking for the ones he'll come up with without having to puzzle them out.
It's telling that Microsoft were the ones who went to eWeek with the story, without consulting Cohen or asking for his OK on telling the world about the meeting. Since Microsoft were also the ones asking for the meeting in the first place, one has to wonder whether it was done solely to be able to place a piece like this?
Actually one doesn't have to wonder, knowing Redmond.
I'll take first-to-file with one condition: if anything the patentholder claims infringes on their patent can be shown to have been described either to patentholder or in public prior to the patent's filing date, the patent's automatically invalidated. If the patent application disclosed the prior description, only the claims alleged to have been infringed are invalidated. If the patent application failed to disclose the prior description, it's considered evidence of bad faith and the patent's invalidated in it's entirety (but remains on the record and counts as description for purposes of other patents).
I'd also add a patent filter process. The end result (not the methods) described in the patent is presented to a randomly-selected half-dozen or so people competent in the field. They get 5 working days to come up with ways to achieve that end result. If any of them come up with the method described in the patent, without having seen the patent's description of the method, the patent is denied on the grounds of obviousness.
My problem with DRM isn't the concept itself, it's the one-sidedness of current implementations: the existing DRM systems enforce the rights the media companies want enforced, but they don't enforce the rights copyright law grants to copy-owners. An open DRM system at least offers the ability to lay down within the system all rights including the ones copyright law grants that the media companies don't like. If we lay down the standard with reference to relevant statute and case law, we can change the playing field so the media companies have to argue why a DRM system shouldn't comply with the law when they object to things like time-shifting and personal-copy rights.
There's another issue of licensing to consider when figuring TCO, and that's your upgrade path and timing in the future. Microsoft has, the last 2 times they went to update their licensing terms, tried as hard as they could to move those terms to an annual-subscription basis, and they don't seem to have given up on the idea. From their standpoint it's a good one, it guarantees their cash flow. If you buy Windows under those terms (and if MS has any say in it you wouldn't have a choice), come time to renew your licenses you might end up in a bind:
- Upgrading to the most-current version of Windows would be expensive and inconvenient in terms of hardware and third-party-software upgrades, and right now your business is better served by spending that money and effort elsewhere.
- Microsoft won't accept payment and renew your licenses, because they've end-of-lifed that version of Windows and don't sell annual licenses for it anymore.
- If the licenses aren't renewed, all of your machines stop working completely the day after the licenses expire, shutting your business down completely.
Considering that Microsoft has tried to make this world a reality in the last 2 iterations of their licensing revisions, and that the majority of the corporate world is using a version of Windows that, while only 1 version behind the most recent stable version, is slated to be end-of-lifed at the end of this year, I think the above scenario has to be taken seriously.With open-source systems, at least you have options here. Your support contracts may end, but you never have to worry about the actual systems ceasing to work because of that. If you absolutely need support, you can buy it from another party if your original vendor won't give it to you. And in the absolute worst case you can hire some geeks to maintain it in-house. You can decide for yourself, based on your business needs, when and how to upgrade your systems, without any real fear that your vendor will force an upgrade on you at effective gun-point.
Take a look at the bottom-right corner. If a site's tried to set unallowed cookies, or tried to create a blocked pop-up, there'll be one or more icons down there. Clicking on the icons will bring up the appropriate dialogs to let you configure things.
One thing the "cookies aren't usually deleted" crowd tends to gloss over is the ability of browsers to force cookies to be session-only, or to delete cookies when the browser closes. People set up for this appear to all the stats engines as accepting cookies, but cookies set on them don't persist the way the stats engines expect them to. I think they gloss this over because it's all but impossible for a stats engine to detect this situation and count it.
The best estimates I can come up with are that something like 5-6% of all users have their browsers set to force even cookies from the site's domain to session-only (or discard them upon browser close), and something like an additional 16-17% either block third-party cookies completely or discard them at the end of a browsing session. And those percentages have been trending upwards over time.
It'll be worse, the retailers will get in on it. They'll be getting all sorts of returns from people who don't have an Internet connection. Parents whose player doesn't work after little Johnny unbeknownst to them tried to play a disc his friend at school gave him. People whose player got "self-destructed" because somebody at a content provider mis-keyed a serial number. And people won't be happy about having to pay restocking or repair fees when they didn't do anything to break the player. A few consumer complaints later, Blu-Ray players will be anathema to retailers who can't afford to eat the cost of all those returns.
One program I've had luck with is the HTML Tidy program at http://www.w3.org/People/Raggett/tidy/. It seems to clean up code (particularly from Word) quite a bit.
First, ignore all the per-capita methods. They won't work.
Now, take your lists of what you need to spend and what you want to spend. Lay out the items, give each one a priority ranging from "must have" to "would be nice". Provide a justification for each one and for the priority you gave it. Give all justifications, not just the best one, with examples from reality (eg. the justification for the anti-virus software might make reference to actual virus infestations in the company in the previous year and how much they cost in money, time and resources). Be sure to account for recurring costs in future years (eg. the service contracts on equipment, anti-virus update services, etc.).
Once you've got your list, sit down with the Finance guys and figure out how far down the list the business can afford to go.
Realistic budgets aren't based on per-capita expenditures or percentages of revenues or profits, they're based on what the business actually needs to spend to stay in business.
There already are things to do this. Most distributions come with a graphical system-configuration tool that does exactly what you describe for the major packages. There's no real need for another layer on top of that for remote management, any X11 app is automatically remoteable (X11 beneath the GUI simply doesn't distinguish between local and remote displays, so anything you can run locally you can run remotely).
Of course, I don't like the GUI tools for one basic reason: history. Not my history, the config file's history. If I maintain my config files directly, I can keep them in CVS and maintain a history of exactly what changed when in them. Comes in real handy when something suddenly breaks and I can go back and a) check whether the files being used match the last known versions I have, and b) review the exact sequence of changes to see what could have caused the problem. I haven't seen any management tools in Windows that offer this form of change history to me. If I'm managing multiple servers, I maintain the files in CVS on a central machine, make my changes there, vet them, then use rsync or rdist to propagage the changes out to the machines that need them and do any command sequences that need done before or after applying the change.
A final advantage of text files as the ultimate configuration source: I can edit text files just about anywhere. I don't always have access to a Windows machine, nor do I always have access to one with an open enough firewall to let me connect via the management protocols I need. I've rarely found anywhere where I couldn't SSH where I needed to, though, and if I've got a terminal window I can call up vi and edit those nasty, primitive text files from my cel phone if I have to. It's good insurance knowing that your admins can do anything they need to do any time they need to do it without having to worry about setting up a VPN or reconfiguring a firewall to allow the needed protocols through (or worse yet, not being able to do those things because the only network they've got access to doesn't allow taht).
First, he talks about demands for fixes within 15-day or 30-day periods. Sorry, wrong. The behavior that causes so many people to push for full disclosure is vendors not even
As for tying seceurity releases and disclosure to financial quarters, sorry but no. That's not the vendor's call to make, it's mine. If the problem's severe enough I may have to overrule procedure and test and implement the fix regardless. But the vendor can't decide that for me, and I can't decide it for myself if the vendor's not telling me "for my convenience".
I know Walmart (blechptooey) has a solution to a lot of this. When they ring up your sale, the receipt goes into their computer system. When you go to return an item they don't trust the paper receipt you've got, they pull up the record from the computer. Then they update the record to reflect the return, and print you a new receipt if you need one (eg. you haven't returned everything on the receipt). If you try to reuse the receipt to return the same thing again, the electronic record will trip you up. As far as I can tell, they update the records in real-time so even if you immediately to go another store they're be able to see your return and will refuse to take the second try.
As for the problem of people substituting cheaper items in the box and getting money/credit for the more expensive one, there's another simple solution to that: hire clerks who know your products. Of course you probably won't be able to get them for minimum wage, but them's the breaks. The store'll just have to decide which costs them less: paying higher wages or eating losses due to lower-quality employees.
I think the prevalence of the problem goes back to store policies at least in part. More and more often, stores have implemented draconian policies on returns. Often they charge 10-20% restocking fees even when the merchandise genuinely and obvious was defective when bought. That contributes a lot to customers deciding "Well, they're screwing me over every change they get, why shouldn't I play by their rules?".
What if you tell me that a particular task takes 80 hours, but in reality it takes you only 20? I have no way of knowing that I'm wasting 60 hours!
You're trusting me to create the software that's going to determine whether your business succeeds or fails, but you don't trust me to be honest with you about schedules? I think you've got a more fundamental problem, then. Either you can't trust me period, or your expectations on schedules are out of line with reality and nothing can be done until you correct your expectations. Oddly, I've found the latter to be far more often the case (this was in fact the primary reason I changed jobs earlier this year).
If I have you in a cubicle, I can look over your shoulder and make certain that you are working, I can monitor your browsing, check for personal emails, etc - in other words, I can track how you're spending your time and if you're ripping me off I'll know it.
And why do you need to do this? You hired me to do a job. Either I'm turning in the results on time and to spec or I'm not. If I'm not, you might need to watch me closer to figure out why. But if I'm finishing my projects on time and my schedules are reasonable, why should you need to confirm that I'm doing what I'm obviously doing?
I think the lack of maturity here isn't on the developers' side. I've found most commonly that managers lack the maturity to trust highly-paid professionals to simply do their job unless and until there's evidence they aren't.
I need specific details for a couple of things. Firstly is to evaluate whether this is a real problem. A lot of problems are highly configuration-specific, and I need to test not just whether it's a problem in the general case but also whether it's a problem that I can be bit by given the configuration of my particular network. In addition, I need to be able to test any fixes Cisco might put out. Vendors have had histories of putting out "fixes" just to say they have, but the fix only deals with the one particular example and leaves everyone exposed to even trivial variations on the original attack (eg. dealing with Code Red by blocking the one specific URL string used, leaving you vulnerable to Code Red with one character in the padding changed).
I keep seeing how vendors react, and it's always "the researchers need to compromise". The vendor's position is always "no release of any information period". We gave them right of first notice, we gave them time to fix the problem before details were released, and after that they still seem to want more compromises. I've become convinced that they won't stop compromising short of their own position, and that as long as that's the case the only response can be no compromise at all.
I wonder what would happen if a large user of network equipment, who depends on that equipment operating properly to stay in business, filed against Cisco on this? After all, they know how dependent others are on their equipment, they knew their errors in coding had put those other people at risk, and they not only didn't do anything about the situation they actively tried to block information from the people who'd be harmed. Seems to me that if a dangerous situation existed and the person responsible for it actively tried to keep the people endangered from finding out about it, that's usually grounds for additional penalties against the responsible party.
On the other hand, knowing about the problem I can now take steps to mitigate it by, for example, making sure my back-up routers are not made by Cisco, or by replacing vulnerable equipment with other types that aren't vulnerable. Of course this would hurt Cisco, which is the reason IMHO they tried to shut the guy up.
Do remember that there's limits on non-compete clauses. They apply if the employee quits or was dismissed for cause. They do not apply if the company dismissed the employee for no cause or if the employee is otherwise not responsible for the dismissal. I recall one of the claims Mr. Lee made was that Microsoft wasn't assigning him work and providing him opportunities appropriate to his skill. That reminds me of the seminal "constructive dismissal" case, and if Mr. Lee can successfully make that argument before the judge then Microsoft is out of luck (and may be liable to Google for interfering).
Only problem is, if you wait until they ask it's going to take you time (and lots of it) to re-design and recode everything. They're likely motivated by something major, eg. possible legal liability if they continue to allow known security problems, and you're then going to get back from them "Well, we can't wait N months for you to convert. Your competitors already support non-IE browsers, we're going to them.".
Then they wouldn't need the databases the EFF found linking the serial number of the printer to the identity of the person who bought it, would they? The existence of those databases seems to imply that the government at least planned to be able to track a document back to the person who printed it (or at least owned the printer used).
GMT's a good thing for computers, a bad thing for humans. The whole idea of timezones in the first place is to put noon on the clock at roughly the same time as noon by the sun. DST is an annoyance because it shifts things around inconsistently without actually improving sync between clock and sun.
If you've sense you get the offer and acceptance in writing and signed, with a listing of exactly what conditions still need to be satisfied before your first day of work, before you hand in your resignation at your old job. And make sure any conditions listed (eg. passing a drug test, etc.) are acceptable and don't have loopholes (eg. no generic "pass a background check" language, have them spell out exactly what sorts of things would disqualify you if they turned up in your background check). Then if they try the "You need to agree to these new terms, they're standard for all employees, if you don't we can't hire you." line, you can say "Sorry, you already hired me. See, here's everything all written out with signatures from your company's representatives, and that agreement isn't mentioned anywhere as a condition of employment.". They can still refuse to pay you, but they'll have a hard time in court getting past those signed documents.
I get riled up over the inability of the telemarketers to accept it when I say "Thanks, not interested, take me off your list.". After telling the same company that 18 times in one month, it gets a tad old.