IANAL, but I don't think a contract would give you an expectation of privacy or have any influence on whether or not they can legally turn your information over to the feds (or anyone, really). If they turn your data over to law enforcement, even if your contract prevents it, they're just liable for the damages coming out of that breach of contract, and "damages" of the form of "it got me convicted of a crime" aren't normally things you can sue for.
The whole ownership/lease thing clouds up a number of these analogies. The real issue (IMO) is possession.
If you loan your car to a friend, and your car has a bunch of drugs and child porn in it, there's no law that says your friend can't root around your stuff, call the cops, and consent to a search of your car. Your friend has lawful possession of your car and is legally entitled to do all of these things.
When you contract for services with an ISP or an e-mail provider, you are giving them possession of your data. There's no law that says they can't turn it over to the cops. Even if it's in the contract between you and your ISP, breach of contract is a civil dispute that has nothing to do with the admissibility of the evidence.
I suspect the parent poster is talking more about possession of the data than a transfer of your copyrights. In addition, ISPs are not considered common carriers, though they may be utilizing common carriers to send and receive your data.
If you have drugs in your car, and you loan your car to a friend, there's no law that says that they can't root around in your things, they have to be discreet about what they find, or that they can't drive up to a police station and let the cops have their way with your stuff. Your friend has lawful possession of your car, because you let them have it.
Your mail provider has lawful possession of your data, because you set up an e-mail account there. Your ISP also has lawful (though usually more brief) possession of your data, because that's the point of contracting for Internet service. You understood that by giving your data to them, they would send it over the Internet to its destination. Your ISP has business arrangements with other ISPs to make that happen. These ISPs must necessarily possess your data for a short period of time in order to perform the services you contracted with your ISP to perform. There is little (IF ANY) law that requires them to keep it confidential. (At least, that is the argument of the State.)
Even if you have some sort of contract with the friend (ISP) that says they do things to your car (data) that you don't want, there's no law that requires them to obey it. Worst case you take them to court for damages from their breach of contract. This will have no effect on the admissibility of the evidence.
Why more people don't use encrypted email boggles my mind.
Is there some keyboard shortcut in Google Mail that I'm missing? People don't use encrypted mail because it's not readily available. Yes, the technology has been around for decades, but until it's pointy-clicky accessible via all of the major e-mail providers, it'll never go anywhere.
AT&T also refuses to provide a structured layout plan of where they wish to deploy these 52B boxes (for all we know, it might end up in someone's front yard 5ft from the house). The people in some of these towns do not want that.
If AT&T wanted to put these boxes on private property, they're required to make an agreement with the property owner to do it. (In fact, the article specifically discusses these situations as ways AT&T is successfully getting their upgrades accomplished without requiring public approval.) The property owner is perfectly within his rights to say no, or to hold out for money.
The issue is with the public right-of-way, not private land.
Why not make the key some random digit string, printed inside the passport in machine-readable text? Then it would at least be impossible to read the passport without opening it.
Off the top of my head (might be missing something obvious), by forcing the key to be made up of useful data, it becomes impossible to divorce the key from the holder's identifying information, as printed on the passport. By requiring the operator to enter the user's data as part of the key to decode the electronic data, it sort of requires that the printed data match the electronic data. Without this check, the operator would have to visually compare the two, which might make it slightly easier to attempt low-tech forgeries where the information doesn't actually match.
Of course, even if that were one of their reasons behind the design, that wouldn't excuse them from not mixing the passport holder's data with a random number in the manner you suggest.
It's conceivable that both said the same thing, in their own way, with no influence from the other. From The Restaurant at the End of the Universe (emphasis mine):
The major problem—one of the major problems, for there are
several—one of the many major problems with governing people is
that of whom you get to do it; or rather of who manages to get
people to let them do it to them.
To summarize: it is a well known fact, that those people who most
want to rule people are, ipso facto, those least suited to do it.
To summarize the summary: anyone who is capable of getting
themselves made President should on no account be allowed to do
the job. To summarize the summary of the summary: people are a
problem.
This really ought to make people think about who they're electing for office. If you choose a leader or a legislator for yourself, and that person inflicts costs on your community, you have no one to blame but yourself. The voters need to take a little bit of responsibility here. Maybe they'll write more letters to their leaders about things like this in the future to avoid having their community funds go toward compensating someone for their government's stupidity.
The arrangement I tend to advocate revolves around four teams:
Development
The guys producing software. They shouldn't need to know anything about the servers, though potential server configurations need to be part of their requirements, so they don't do something stupid that prevents them from running. Software defects go to this team to be resolved. Things like data sources, remote services, usernames and passwords, etc., are specified through configuration, not hard-coded.
Deployment
The deployment team takes the software and deploys it on test/stage servers, and later on production servers. They are responsible for obtaining access to servers, data sources and other services and for configuring the application to use them. They may set up usernames and passwords, etc. This may be independent of, or a sub-team of either the development team or the Production Support team. Just pick one, define the lines of responsibility and stick to it.
QA
The QA team looks at the original requirements and verifies that the application meets those requirements. This could include functional testing and performance testing. This needs to be a team completely independent of the development team.
Production Support
This is the team that maintains the servers and the health of the application. They need to monitor the functionality of the application, analyze logs, and troubleshoot problems. If a software defect is likely, they submit it to the development team, but their job is to keep service going even in the face of defects, and to like it. (It may be cheaper to dedicate someone to nursing an application than it is to fix the defects that make that necessary. Suck it up.)
If you have a hard time justifying this type of arrangement to your management, tell them that separating roles and responsibilities this way, and formalizing the interface between these teams, makes it pretty easy to outsource the Development role to India, because you'd have to do it that way anyway.:)
If not more. We routinely have 4+ tiers. One for developers to experiment. One or more test tiers for developers to integrate all of their code in preparation for a release. (Sometimes multiple releases could be going on simultaneously.) Separate stage and production tiers (similarly if not identically configured) allow for pre-release testing and the release itself. The stage tier, if configured identically to production, also allows for stress/performance testing. If you have lots of similarly-configured production tiers for other applications, you might be able to share a single stage tier between them, but that then requires coordination and scheduling. A second stage tier may be desirable for a large release, or a middleware upgrade, so that you can manage your current release while preparing for your next release (allowing you to back-out and still have a stage tier to work with to resolve defects in the older release).
Once you get to this scale, though, it becomes advantageous to start automating your provisioning. When you need a new set of servers/tier, submit a request, get an assignment out of a pool, do your thing, and release it when you're done.
At a minimum, a company needs a semi-independent Production Support organization. The problem I have with ours is that nobody ever took the initiative to decide, at a high level, who would get what responsibilities. Consequently, Production Support tries to do the minimum amount of work they can while achieving the minimum amount of liability in the event something goes wrong. Ultimately all they do is set up and upgrade servers, and click the button to deploy software to production servers. The development team assumes ownership of all other roles/responsibilities, allowing Production Support to shrug and point the finger when the app breaks after they click "Deploy".
Don't let teams negotiate this stuff at the low level, because they don't know what the hell they're doing initially, and only care about minimizing their work/headaches in the long term. Divide responsibilities meaningfully to your business at a high level and require them to stick with it.
I have to agree with the post you're replying to. I work at a major telecommunications company in a large IT department, and "needs of the business" trump "correct" every time. Projects are always due-date-driven, not quality-driven. In theory, if a deployment team should do deployments, but if they have to rush to meet their due dates, you can bet the developers are just as much on the hook and are going to be the ones up in the middle of the night. Eventually someone asks, "Why don't we just make the development team responsible for this permanently?" Unless you can respond to that question in a way that directly translates to getting the work done faster or cheaper, there's just no point in trying.
There is a HUGE difference between companies that sell software, and companies that produce software for internal use. With both companies, it's the bottom line that matters. But when you sell software, the quality of your software is directly tied to your revenue (monopoly situations notwithstanding). It's in your best interests to do things "correctly" in these situations. But if you're just producing software for internal use, you're not making any money from selling that software. There's no reason to strive for quality, and you focus instead on costs. It is preferable to have defects and poor process, because it is cheaper to deal with defects and poor process than it is to design and implement everything correctly. Everyone hates this except for management.
If you want to have a good software development experience, work for a company that's in the business of producing software.
Now, the obstacle you're likely to hit is office politics. People won't want to listen to others and/or won't want to give up their turf or allow others on it.
I work in a large IT organization, and my experience is similarly negative, but exactly the opposite: Production Support wants nothing more than to have zero liability and zero work. Consequently, they think of every possible way they can push responsibility onto the development teams, including giving access to production servers. Stability isn't as important as being able to point the finger at someone else when something fails, so there's really no incentive for them to take ownership if they don't have to.
Granted, not all of Production Support works like this, but enough does to demonstrate that the whole "treat your organizations like mini-companies" thing doesn't always work. Maybe we're too big for a socialist model to be effective and we need to set multiple IT departments in competition with each other.
You probably want to set an Expires header here too for HTTP 1.0 user agents.
Other users may want to consider using "Header add" rather than "Header set" so as not to overwrite other Cache-Control headers set elsewhere in the handling of the response.
It's important to be aware that the max-age cache-control directive is only one part of a site's caching strategy. The presence of Last-Modified headers and/or Etag allow for Conditional GETs, which are also great at improving a site's performance. Yes, browsers still have to make a request against the site, but it takes far less time to handle a 304 response than it does to retrieve and handle the resource's content under a 200 response. You should balance your freshness requirements against your need to have resources served out of local or shared caches. Your query string approach is fairly hackish and only works around undesirable caching policies rather than making the caching policies work for your content requirements.
Keep in mind that it's entirely likely that browsers aren't even going to respect some of these Cache-Control headers over the lengths of time you're specifying here. You'll probably get more predictable results with age requirements on the order of hours or a day, at most. (Browsers will still make conditional GETs and your server can still respond with 304s even if a cached resource is no longer fresh.)
Your workflow for planned content changes could involve changes to a page's Expires or Cache-Control headers well in advance of the change to ensure old content will be expired when the new content needs to be published.
The contents of the.htaccess file are only parsed when the.htaccess file is changed. Each request will still cause a stat to occur, but chances are, for frequently-requested files, this will be handled out of memory without requiring a hit to the disk. There is a small performance hit for the stat invocations, but it's pretty small, especially compared with the IO that occurs to actually fetch and deliver the resource that was requested. (And, as you already note, a stat seeking a file that doesn't exist is probably just as expensive as one seeking to see when a.htaccess file was last updated, so you're already incurring the performance hit.)
Unfortunately all of this is speculation; I'm not aware of any concrete numbers that show how performance is impacted.
You should need to change filenames. You just need to come up with a good age/expiration scheme for whatever content you want to see cached.
If you're making regular changes to a particular piece of content, your max-age and/or expiration date needs to be set up to facilitate that. If you change something every day at 6am, set your expiration date for 6am. If you could change it at any time, and you want to see changes picked up within an hour, set a max-age=3600. Let your caching policies work with your content management policies, and you won't have to do invasive things like this.
If your standard caching policies are such that you normally are OK with things being cached days or even weeks at a time, and you anticipate making a change in a week, set the expiration date of the resource to be the date you anticipate making the change, and set the max-age of the cached resource low enough that anyone requesting the resource now knows to check back when the change occurs. Maybe add a must-revalidate directive to ensure everyone has the freshest copy. Then, make your change, and bump up the age/expiration date again.
It really pays to read up about how HTTP caching works. Too often I see kludges where developers just want to work around caching when it doesn't work like they want it to, when they could save themselves a headache by just configuring it properly in the first place.
Only a few dictionaries have started suggesting that "insure" could have the same meaning as "ensure". While I agree with their motives, tracking popular usage, you still will not see any reputable publisher using "insure" to mean "ensure". Maybe you will in another generation, I don't know. Yes, it's becoming popular usage, but it's becoming popular usage because people are using it incorrectly, which, IMO, is a good reason to resist. If this were simply a new word, or an existing word used to describe a brand new thing (for which another word does not exist), that's usually an acceptable evolution of the language. But when it's "popular usage" only because people don't know how to spell, I'd rather point it out as an error, even though a minority of dictionaries have picked up on it.
Companies write dictionaries, and companies are in business to make money. Dictionary companies are in business to give you books that let you determine the meaning for words. Dictionaries are not necessarily intended to show you what is correct and what is not, though many attempt that. If a word is becoming popular, it is in the best interests of some dictionaries ($$$) to point out its meaning. This should not imply that it's acceptable English in educated circles.
Unfortunately this isn't as tidy a solution as you probably would like, but it's the best one can do, IMO. If it's found that infringing code is in your project, you're still technically infringing their copyrights. Even though you can point to someone else and say, "It's their fault!", you're still on the hook if they don't get what they want out of the other guy. (Of course, you'd have a really good case against the other guy if you end up losing, but if he has no money, you still might be SOL.)
It's all about balancing costs and risk. What is the likelihood that this will happen? How much would it cost if it did? What are the costs to mitigate it? Getting something in writing from contributors, and ensuring you have good contact information, are great first steps.
RTFA. The software/drones are semi-autonomous. The pilot only needs to direct them at a high level. Yes, they will require some of his attention, but he's not scrambling to manage 5 different sets of flight controls. The whole point of the exercise was to see if it would work.
Providing a method for "experts" to digitally sign Wikipedia pages won't fix that, because peopel who don't care to check sources also won't care to review the qualifications or appropriateness of the "expert" that signed the page, or even pay attention to whether or not it is signed.
SSL certificates had the same issue to overcome, but it is solvable. Take the issue of checking for trust out of the user's hands. Users don't validate SSL certificates. The PKI establishes rules for trust, and how that trust should be used. A system like this would be no different. Many fields that are the subject of Wikipedia articles have expert communities of some form, either professional organizations, universities, scientific organizations, etc. Many of these already have well-established means of saying, "We trust this guy to give you the information you're after," because they're asked a lot.
So we have the means to solve this problem (at least partially) through automation, without ever requiring the users to decide who to trust, and for what topics.
... or even pay attention to whether or not it is signed.
There is no way to "change the system" so that people whose "habits and perceptions" are to accept anonymously-written secondary sources as reliable without any kind of critical analysis or review of sources are going to get consistent, reliable information.
Here too, SSL certificates have had to deal with this problem already. The solution we're moving toward is good UI. Put a block of text above the article, with verbiage such as this:
(!) This engineering article has received no endorsements from the Society of Professional Engineers, or any other source that you trust for this purpose. The information contained within it may be inaccurate or may not reflect expert consensus.
As opposed to:
(i) This article has been endorsed as accurate by Bob, Alice and Jane, sources that you trust to endorse articles in this category.
Many professional/scientific fields have professional organizations. Have them endorse their own experts, just like they do when someone calls them and wants to assemble a panel for some function. Use this to set up your initial, first-line chain of trust.
Some "expert" sources already have a clear chain of command, such as the CDC in the US and many other facets of one's government.
Users that prefer to trust non-mainstream sources could take it upon themselves to add their own sources to their trusted sources list, but it's unlikely that many of these sources will have long-lived contributions to Wikipedia, so this may not even matter.
There's no guarantee that an article, at any moment in time, even approaches accuracy. If an expert in a field has reviewed some piece of information within it, perhaps a mechanism allowing him to digitally sign that piece of information would allow the article to gain some credibility.
In theory, citations should achieve the same goal, but it's clear that people don't want to research Wikipedia articles that have already been written. They want to use them as research. Do we want to work to try to change people's habits and perceptions, or change the system to work with people's habits and perceptions?
Slashdot Mirror
IANAL, but I don't think a contract would give you an expectation of privacy or have any influence on whether or not they can legally turn your information over to the feds (or anyone, really). If they turn your data over to law enforcement, even if your contract prevents it, they're just liable for the damages coming out of that breach of contract, and "damages" of the form of "it got me convicted of a crime" aren't normally things you can sue for.
The whole ownership/lease thing clouds up a number of these analogies. The real issue (IMO) is possession.
If you loan your car to a friend, and your car has a bunch of drugs and child porn in it, there's no law that says your friend can't root around your stuff, call the cops, and consent to a search of your car. Your friend has lawful possession of your car and is legally entitled to do all of these things.
When you contract for services with an ISP or an e-mail provider, you are giving them possession of your data. There's no law that says they can't turn it over to the cops. Even if it's in the contract between you and your ISP, breach of contract is a civil dispute that has nothing to do with the admissibility of the evidence.
I suspect the parent poster is talking more about possession of the data than a transfer of your copyrights. In addition, ISPs are not considered common carriers, though they may be utilizing common carriers to send and receive your data.
If you have drugs in your car, and you loan your car to a friend, there's no law that says that they can't root around in your things, they have to be discreet about what they find, or that they can't drive up to a police station and let the cops have their way with your stuff. Your friend has lawful possession of your car, because you let them have it.
Your mail provider has lawful possession of your data, because you set up an e-mail account there. Your ISP also has lawful (though usually more brief) possession of your data, because that's the point of contracting for Internet service. You understood that by giving your data to them, they would send it over the Internet to its destination. Your ISP has business arrangements with other ISPs to make that happen. These ISPs must necessarily possess your data for a short period of time in order to perform the services you contracted with your ISP to perform. There is little (IF ANY) law that requires them to keep it confidential. (At least, that is the argument of the State.)
Even if you have some sort of contract with the friend (ISP) that says they do things to your car (data) that you don't want, there's no law that requires them to obey it. Worst case you take them to court for damages from their breach of contract. This will have no effect on the admissibility of the evidence.
Is there some keyboard shortcut in Google Mail that I'm missing? People don't use encrypted mail because it's not readily available. Yes, the technology has been around for decades, but until it's pointy-clicky accessible via all of the major e-mail providers, it'll never go anywhere.
If AT&T wanted to put these boxes on private property, they're required to make an agreement with the property owner to do it. (In fact, the article specifically discusses these situations as ways AT&T is successfully getting their upgrades accomplished without requiring public approval.) The property owner is perfectly within his rights to say no, or to hold out for money.
The issue is with the public right-of-way, not private land.
Off the top of my head (might be missing something obvious), by forcing the key to be made up of useful data, it becomes impossible to divorce the key from the holder's identifying information, as printed on the passport. By requiring the operator to enter the user's data as part of the key to decode the electronic data, it sort of requires that the printed data match the electronic data. Without this check, the operator would have to visually compare the two, which might make it slightly easier to attempt low-tech forgeries where the information doesn't actually match.
Of course, even if that were one of their reasons behind the design, that wouldn't excuse them from not mixing the passport holder's data with a random number in the manner you suggest.
It's conceivable that both said the same thing, in their own way, with no influence from the other. From The Restaurant at the End of the Universe (emphasis mine):
Words of wisdom!
This really ought to make people think about who they're electing for office. If you choose a leader or a legislator for yourself, and that person inflicts costs on your community, you have no one to blame but yourself. The voters need to take a little bit of responsibility here. Maybe they'll write more letters to their leaders about things like this in the future to avoid having their community funds go toward compensating someone for their government's stupidity.
Just because a law is ruled unconstitutional doesn't mean the lawmakers have done anything "illegal". What crime do you propose to charge them with?
The arrangement I tend to advocate revolves around four teams:
Development The guys producing software. They shouldn't need to know anything about the servers, though potential server configurations need to be part of their requirements, so they don't do something stupid that prevents them from running. Software defects go to this team to be resolved. Things like data sources, remote services, usernames and passwords, etc., are specified through configuration, not hard-coded. Deployment The deployment team takes the software and deploys it on test/stage servers, and later on production servers. They are responsible for obtaining access to servers, data sources and other services and for configuring the application to use them. They may set up usernames and passwords, etc. This may be independent of, or a sub-team of either the development team or the Production Support team. Just pick one, define the lines of responsibility and stick to it. QA The QA team looks at the original requirements and verifies that the application meets those requirements. This could include functional testing and performance testing. This needs to be a team completely independent of the development team. Production Support This is the team that maintains the servers and the health of the application. They need to monitor the functionality of the application, analyze logs, and troubleshoot problems. If a software defect is likely, they submit it to the development team, but their job is to keep service going even in the face of defects, and to like it. (It may be cheaper to dedicate someone to nursing an application than it is to fix the defects that make that necessary. Suck it up.)If you have a hard time justifying this type of arrangement to your management, tell them that separating roles and responsibilities this way, and formalizing the interface between these teams, makes it pretty easy to outsource the Development role to India, because you'd have to do it that way anyway. :)
If not more. We routinely have 4+ tiers. One for developers to experiment. One or more test tiers for developers to integrate all of their code in preparation for a release. (Sometimes multiple releases could be going on simultaneously.) Separate stage and production tiers (similarly if not identically configured) allow for pre-release testing and the release itself. The stage tier, if configured identically to production, also allows for stress/performance testing. If you have lots of similarly-configured production tiers for other applications, you might be able to share a single stage tier between them, but that then requires coordination and scheduling. A second stage tier may be desirable for a large release, or a middleware upgrade, so that you can manage your current release while preparing for your next release (allowing you to back-out and still have a stage tier to work with to resolve defects in the older release).
Once you get to this scale, though, it becomes advantageous to start automating your provisioning. When you need a new set of servers/tier, submit a request, get an assignment out of a pool, do your thing, and release it when you're done.
At a minimum, a company needs a semi-independent Production Support organization. The problem I have with ours is that nobody ever took the initiative to decide, at a high level, who would get what responsibilities. Consequently, Production Support tries to do the minimum amount of work they can while achieving the minimum amount of liability in the event something goes wrong. Ultimately all they do is set up and upgrade servers, and click the button to deploy software to production servers. The development team assumes ownership of all other roles/responsibilities, allowing Production Support to shrug and point the finger when the app breaks after they click "Deploy".
Don't let teams negotiate this stuff at the low level, because they don't know what the hell they're doing initially, and only care about minimizing their work/headaches in the long term. Divide responsibilities meaningfully to your business at a high level and require them to stick with it.
I have to agree with the post you're replying to. I work at a major telecommunications company in a large IT department, and "needs of the business" trump "correct" every time. Projects are always due-date-driven, not quality-driven. In theory, if a deployment team should do deployments, but if they have to rush to meet their due dates, you can bet the developers are just as much on the hook and are going to be the ones up in the middle of the night. Eventually someone asks, "Why don't we just make the development team responsible for this permanently?" Unless you can respond to that question in a way that directly translates to getting the work done faster or cheaper, there's just no point in trying.
There is a HUGE difference between companies that sell software, and companies that produce software for internal use. With both companies, it's the bottom line that matters. But when you sell software, the quality of your software is directly tied to your revenue (monopoly situations notwithstanding). It's in your best interests to do things "correctly" in these situations. But if you're just producing software for internal use, you're not making any money from selling that software. There's no reason to strive for quality, and you focus instead on costs. It is preferable to have defects and poor process, because it is cheaper to deal with defects and poor process than it is to design and implement everything correctly. Everyone hates this except for management.
If you want to have a good software development experience, work for a company that's in the business of producing software.
I work in a large IT organization, and my experience is similarly negative, but exactly the opposite: Production Support wants nothing more than to have zero liability and zero work. Consequently, they think of every possible way they can push responsibility onto the development teams, including giving access to production servers. Stability isn't as important as being able to point the finger at someone else when something fails, so there's really no incentive for them to take ownership if they don't have to.
Granted, not all of Production Support works like this, but enough does to demonstrate that the whole "treat your organizations like mini-companies" thing doesn't always work. Maybe we're too big for a socialist model to be effective and we need to set multiple IT departments in competition with each other.
Some suggestions:
It's important to be aware that the max-age cache-control directive is only one part of a site's caching strategy. The presence of Last-Modified headers and/or Etag allow for Conditional GETs, which are also great at improving a site's performance. Yes, browsers still have to make a request against the site, but it takes far less time to handle a 304 response than it does to retrieve and handle the resource's content under a 200 response. You should balance your freshness requirements against your need to have resources served out of local or shared caches. Your query string approach is fairly hackish and only works around undesirable caching policies rather than making the caching policies work for your content requirements.
Keep in mind that it's entirely likely that browsers aren't even going to respect some of these Cache-Control headers over the lengths of time you're specifying here. You'll probably get more predictable results with age requirements on the order of hours or a day, at most. (Browsers will still make conditional GETs and your server can still respond with 304s even if a cached resource is no longer fresh.)
Your workflow for planned content changes could involve changes to a page's Expires or Cache-Control headers well in advance of the change to ensure old content will be expired when the new content needs to be published.
The contents of the .htaccess file are only parsed when the .htaccess file is changed. Each request will still cause a stat to occur, but chances are, for frequently-requested files, this will be handled out of memory without requiring a hit to the disk. There is a small performance hit for the stat invocations, but it's pretty small, especially compared with the IO that occurs to actually fetch and deliver the resource that was requested. (And, as you already note, a stat seeking a file that doesn't exist is probably just as expensive as one seeking to see when a .htaccess file was last updated, so you're already incurring the performance hit.)
Unfortunately all of this is speculation; I'm not aware of any concrete numbers that show how performance is impacted.
Sorry, that should read: You shouldn't need to change filenames.
You should need to change filenames. You just need to come up with a good age/expiration scheme for whatever content you want to see cached.
If you're making regular changes to a particular piece of content, your max-age and/or expiration date needs to be set up to facilitate that. If you change something every day at 6am, set your expiration date for 6am. If you could change it at any time, and you want to see changes picked up within an hour, set a max-age=3600. Let your caching policies work with your content management policies, and you won't have to do invasive things like this.
If your standard caching policies are such that you normally are OK with things being cached days or even weeks at a time, and you anticipate making a change in a week, set the expiration date of the resource to be the date you anticipate making the change, and set the max-age of the cached resource low enough that anyone requesting the resource now knows to check back when the change occurs. Maybe add a must-revalidate directive to ensure everyone has the freshest copy. Then, make your change, and bump up the age/expiration date again.
It really pays to read up about how HTTP caching works. Too often I see kludges where developers just want to work around caching when it doesn't work like they want it to, when they could save themselves a headache by just configuring it properly in the first place.
Indeed. Thanks for the citations. Looks like I made some bad assumptions.
Only a few dictionaries have started suggesting that "insure" could have the same meaning as "ensure". While I agree with their motives, tracking popular usage, you still will not see any reputable publisher using "insure" to mean "ensure". Maybe you will in another generation, I don't know. Yes, it's becoming popular usage, but it's becoming popular usage because people are using it incorrectly, which, IMO, is a good reason to resist. If this were simply a new word, or an existing word used to describe a brand new thing (for which another word does not exist), that's usually an acceptable evolution of the language. But when it's "popular usage" only because people don't know how to spell, I'd rather point it out as an error, even though a minority of dictionaries have picked up on it.
Companies write dictionaries, and companies are in business to make money. Dictionary companies are in business to give you books that let you determine the meaning for words. Dictionaries are not necessarily intended to show you what is correct and what is not, though many attempt that. If a word is becoming popular, it is in the best interests of some dictionaries ($$$) to point out its meaning. This should not imply that it's acceptable English in educated circles.
Unfortunately this isn't as tidy a solution as you probably would like, but it's the best one can do, IMO. If it's found that infringing code is in your project, you're still technically infringing their copyrights. Even though you can point to someone else and say, "It's their fault!", you're still on the hook if they don't get what they want out of the other guy. (Of course, you'd have a really good case against the other guy if you end up losing, but if he has no money, you still might be SOL.)
It's all about balancing costs and risk. What is the likelihood that this will happen? How much would it cost if it did? What are the costs to mitigate it? Getting something in writing from contributors, and ensuring you have good contact information, are great first steps.
RTFA. The software/drones are semi-autonomous. The pilot only needs to direct them at a high level. Yes, they will require some of his attention, but he's not scrambling to manage 5 different sets of flight controls. The whole point of the exercise was to see if it would work.
SSL certificates had the same issue to overcome, but it is solvable. Take the issue of checking for trust out of the user's hands. Users don't validate SSL certificates. The PKI establishes rules for trust, and how that trust should be used. A system like this would be no different. Many fields that are the subject of Wikipedia articles have expert communities of some form, either professional organizations, universities, scientific organizations, etc. Many of these already have well-established means of saying, "We trust this guy to give you the information you're after," because they're asked a lot.
So we have the means to solve this problem (at least partially) through automation, without ever requiring the users to decide who to trust, and for what topics.
Here too, SSL certificates have had to deal with this problem already. The solution we're moving toward is good UI. Put a block of text above the article, with verbiage such as this:
(!) This engineering article has received no endorsements from the Society of Professional Engineers, or any other source that you trust for this purpose. The information contained within it may be inaccurate or may not reflect expert consensus.
As opposed to:
(i) This article has been endorsed as accurate by Bob, Alice and Jane, sources that you trust to endorse articles in this category.
Many professional/scientific fields have professional organizations. Have them endorse their own experts, just like they do when someone calls them and wants to assemble a panel for some function. Use this to set up your initial, first-line chain of trust.
Some "expert" sources already have a clear chain of command, such as the CDC in the US and many other facets of one's government.
Users that prefer to trust non-mainstream sources could take it upon themselves to add their own sources to their trusted sources list, but it's unlikely that many of these sources will have long-lived contributions to Wikipedia, so this may not even matter.
There's no guarantee that an article, at any moment in time, even approaches accuracy. If an expert in a field has reviewed some piece of information within it, perhaps a mechanism allowing him to digitally sign that piece of information would allow the article to gain some credibility.
In theory, citations should achieve the same goal, but it's clear that people don't want to research Wikipedia articles that have already been written. They want to use them as research. Do we want to work to try to change people's habits and perceptions, or change the system to work with people's habits and perceptions?