How do you know it wasn't encrypted and password-protected? You have to decrypt and provide a password to access an encrypted and password-protected volume, right? The problem here is that the moron had Limewire configured to scan for and share everything on his system, including the sensitive stuff. If he did this after he'd opened the encrypted volume, Limewire would have been able to access it like any other file.
We try to avoid letting DMZ hosts contact internal servers whenever possible... The master puts together the zone files using an in-house templating system
Both of these are great reasons to populate your masters with your zone data out-of-band.
And what's the benefit?
Dynamic updates become difficult if your masters get their data OOB, since they have no way of knowing how to propagate those updates back to the source. It just depends on your needs and your setup. For the majority (?) of configurations, having an inaccessible master doing zone transfers to exposed secondaries is perfectly reasonable. For more complex setups such as yours, it's not, but that design has its own set of costs.
Clearly, there are differences between "slave" and "master" in BIND's logic, but from a practical perspective, what's the difference?
You're absolutely right: a compromised server can't be trusted to give faithful replies, regardless of how bind has it configured. I think the recommendation to not run your primaries exposed is intended to protect the zone data itself, not the queries served by the machine (though, in theory, that's what DNSSEC is for). Many DNS configurations involve a single machine that acts as a DNS master, and on that machine are the only copies of the "live" zone files. If that machine gets compromised, it requires a fair bit of manual effort to recover the zone files from backups, replay any updates that needed to be made, and return to service.
In more complex setups (such as yours), the live zone files are not stored exclusively on the masters. They come from Somewhere Else (a config repository, LDAP, whatever), and you need some sort of out-of-band process to get the data to the DNS masters to be served. SSH/rsync/whatever are perfectly fine ways to do that OOB transfer. But for most setups, the simplistic configuration makes the most sense, especially if you have to deal with dynamic updates, where it may be difficult to propagate changes back to your config repository.
TSIG doesn't offer us anything that SSH doesn't.
Which is essentially what I was trying to say: TSIG and SSH solve the same authentication problem, so if your source is a DNS server, and your destination is a DNS server, why reinvent zone transfers?
The next time I mention something about the way I run my network, I'll make sure my explanation is up to your standards. Sheesh.
Run your network however you prefer! Just don't advocate for your design, and rail against more common configurations and their associated best practices, using reasons that do not support your arguments. You have valid reasons to run your systems the way that you do, so use them to justify your design, but be aware that they do not extend to cover other configurations.
DNS queries are not encrypted, so if you believe the contents of your DNS zones should be secret, you'd better hope nobody queries them. You may be interested in TSIG, which can authenticate your secondaries to your master. If you'd prefer to store and manage your zone files "offline", pushing them out to one or more masters through SSH or something might be the right thing to do, but if you already have an internal master, and need to update some public-facing slaves/shadow masters, there's no reason to re-invent DNS zone transfers.
So I'm responding not because I disagree with your conclusions, but I disagree with the logic you're using to justify them:
Because lots of people don't want intruders being able to affect the actual zone data in case an outward-facing DNS server gets compromised.... If having a DNS machine on the Internet that thinks it is a master really is a mistake, when then, BIND9 is a piece of shit. This is the most straightforward thing a DNS daemon should be asked to do.
You start off with a reasonable statement (that you don't generally want compromised DNS servers to allow for the modification of data), but then you say bind9 is a piece of shit because it's a best practice that the masters (which hold the data) shouldn't be exposed to the public. Which is it?
Using SSH to transfer zone data is much easier and more secure than BIND's own zone transfer mechanisms
Would you care to elaborate on that? Doesn't TSIG secure zone transfers? TSIG is just as easy to set up as SSH keys are.
(e.g., you can automate and schedule them)
How much more automated can you make automatic zone transfers? What better scheduling of zone transfers than when the zones are modified?
you don't have to worry about zone transfers through firewalls
The only thing you need to open through the firewall is TCP and UDP port 53. Most firewalls make this easy, because "Serve DNS through the firewall" is a common configuration for firewalls.
Troubleshooting all the weird crap that can happen between different DNS daemons all supposedly doing regular AXFRs is a real pain in the ass. SSH makes life easier.
SSH makes life easier for someone that understands SSH, and does not understand DNS or firewalls.
That being said, there are valid reasons you might not prefer to run a DNS master as the source for your slaves/shadow masters, and SSH might even be a good way to push your zone files out to those machines, but you have not provided any of those reasons.
What part of that phrase confuses you? He's talking about revenue. That he makes in the future. That is potential, because individual photographs might not license well in the future, but some percentage of his portfolio probably does. And that revenue would be lost if he gave away his rights. What's the problem?
You don't seem to get it. It's not ONLY A OR B, it's AT LEAST A OR B.
I'm a bit baffled by this statement. I suspect you've misunderstood something I've written. I'm certainly not advocating "A or B, at the exclusion of everything else."
The fact that a browser doesn't conform does not make the spec useless, it makes the browser useless. The fact that you think otherwise is a perfect example of how backwards this whole scenario is.
I think I understand now. You seem to think a spec is the place for you to force everyone to do what you want them to do (adopt a free video codec). You seem to be under the mistaken belief that the spec carries the force of law, or that some magical property of the spec will make browsers useless until they follow the spec. Every browser out there ignores something that's codified in a spec today. IE in particular does this quite a lot, yet it still has a clear majority in the browser market. Are you really suggesting that IE is useless? Or is it just useless to you?
I believe that a spec is the place to encourage interoperability. This means the spec must necessarily reflect reality, not a utopia. "Gosh, it would be nice if everyone did X, so let's prescribe X" is stupid if everyone is already doing Y, but it's smart if nobody is doing anything yet. If people have already decided what they're going to do, the spec should reflect that, not prescribe something entirely different. You can't achieve interoperability if you ignore reality, because people must ignore the parts of the spec that disagree with reality if they want interoperability. This makes (these parts of) the spec useless.
So, saying "at least H.264 or Ogg" is (IMO) better than saying "at least H.264" or "at least Ogg", because the latter two will disagree with reality, and will need to be ignored by implementers. But saying "at least H.264 or Ogg" is like saying "at least PNG or GIF", and we don't have that in the HTML standard either. If you wish your argument to be consistent, you should advocate for that as well (along with audio formats). I personally don't believe codecs and file formats are necessary for the HTML spec, for reasons I've already given (and for the same reason I find adding "at least GIF or PNG" silly).
If you say "A OR B" then that means web sites know to provide AT LEAST one stream in either A or B
But the converse is not necessarily true. Just because it isn't in the spec doesn't mean that web site authors do NOT know that H.264 or Ogg are the two codecs supported (individually) in all web browsers. This isn't like some ambiguity in HTML rendering here where there can be as many implementations as there are interpretations, in as many combinations as there are ambiguities and browsers. You can either choose to support a codec, or choose not to. Anyone in the position to be making such a decision is going to be intimately aware of the codec options that are out there, what other browsers support, and what web sites make available.
I'll turn the implication in my previous post into an outright question: Why haven't we standardized on "GIF OR PNG" in the HTML spec too? Do you believe that is necessary? If not, why <video> and not <img>?
importance of a specification that can be easily and freely implemented
A specification that is lacking is exactly as useless as a specification that is ignored. So long as companies feel they have a reason to avoid Ogg, it doesn't matter a bit whether or not the specification says Ogg must be supported. There is no law saying implementations must follow the spec. This is why I perceived your statement as flippant: there is more to the question of whether or not to implement Ogg than how "free" it is. You come across sounding like an open source fanboy when you suggest the solution to the problem is to use the "free" solution. "Like, OMG, duh!" Things aren't quite that simple.
"... fuck this, I give up" means that the big boys will support H.264 in the browser and on the site, and smaller sites will have to pony up for licensing or have a bunch of people who can't play their shit.
I assume you're talking about leaving the codec question undefined? Wouldn't saying "H.264" or "H.264 OR OGG" in the specification potentially lead to this same result? Are you advocating for a more specific standard, or for Ogg specifically?
IANAL, but I suspect the intent of that provision is to permit them to prosecute when they have pictures of someone that is obviously a minor (a child in the physical sense). If someone has sexually-explicit pictures of someone that is very clearly ~12 years old, you shouldn't have to jump through hoops to identify this one person (which could be anywhere in the world), and prove their age. I don't think the intent is to allow them to point to a picture of a sexually-mature (but young) woman, say they're a minor, and prosecute you for having it, without actually proving that they're a minor. If there's a legitimate question of fact about whether the person is a minor, you'd have to get a really stupid or evil jury to let you get convicted for it.
Sure it could. It could also say "EITHER PNG OR GIF", but it doesn't. How much interoperability does this actually buy you? A de facto standard isn't all that different from a de jure one, and they made a point not to standardize on image formats, so maybe it's OK to let this one go too? IMO, this isn't as bad as people seem to be making it out to be. You already have an incentive to choose H.264 or Ogg, because if you're putting content out on the web, you probably want it to be viewable by as many people as possible. Standardizing on "A OR B" doesn't, IMO, improve the world in any measurable way.
Or, you know, just use OGG. It's free.
This is a bit flippant and suggests that you don't understand the nature of the objections to using Ogg.
The thing is, and I can almost absolutely guarantee that Google, Mozilla, and Opera will cooperate here, if they specify a format, the three will eventually conform to it.
Did you read their reasons for avoiding H.264? If H.264 goes into the spec, who's going to pay the licensing costs for Opera to "conform" to the spec? Who's going to pay for the licenses of those that derive their own web browsers from Mozilla or Chromium sources? The reasons companies have for preferring NOT to implement a codec aren't necessarily technical.
We survived fine without explicit HTML standardization on JPEG, GIF and PNG. We'll be fine here too.
If the companies can't agree, that's their problem.... Apparently [W3C needs] to be reminded what their mission statement is.
If the companies can't agree, a spec isn't going to make them agree. Everyone has their reasons for not implementing a codec. Putting a requirement into a spec isn't going to magically solve any of those concerns. It makes it slightly easier for some people to point their fingers and say "they're bad for not following the spec!!1" but it doesn't actually help solve any problems. If anything, it creates a new problem as people try to make their own implementations of the spec, only to discover that they don't interoperate with anyone else because everyone is ignoring that one little part of the spec. If your spec includes stuff that half of your implementers will ignore, deliberately, with full knowledge of the ramifications, then perhaps you should revisit your approach to the spec.
There's nothing that says this can't be revisited later. But for now, it's quite clear that implementers will not implement a common video codec. So what exactly is the point of mandating a common codec in the spec?
Unfortunately I'm pretty sure I have a very slow metabolism
What does that even mean? Your resting metabolic rate is determined almost completely by what it is that you're powering: if you're fat and have larger organs, you need to burn more to support those systems. Two people with identical body types and activity levels will burn the same amount of calories.
ever since I was a pre-teen I would gain weight fairly quickly if I didn't actively work out, regardless of how much or what I eat. (Barring starving myself, I suppose...)
The "regardless of how much or what I eat" sounds wrong and defeatist. If you truly believe what you're telling us, that there's just nothing you can do, and you'll always gain weight no matter what you try, then you're never going to get anywhere. Of course changing how much or what you eat will change how much weight you gain or lose.
This basic equation always holds true: If calories in is greater than calories burned, you gain weight. If calories in is less than calories burned, you lose weight. That's all there is to it. Balance the two however you want.
A can of soda has ~150 calories. Running 1.5 miles will burn ~150 calories. It's far easier to forego that can of soda and drink some water instead, than it is to commit to a 20-minute jog, yes? Both will have the same impact on your weight. The latter, though, will improve your health in other ways. So if you simply can't find time to exercise and increase the number of calories you burn, focus instead on decreasing the number of calories you consume.
If you have a weakness for food, such that you feel you have to "fill up" all the time to curb your hunger, look at the energy density of the foods you eat. Avoid foods that are energy-dense (fried foods, sweets, sodas, processed foods) and start buying foods that have less energy for the same volume, like fruits and vegetables, and anything with a high water content. Drink a glass of water before every meal. Eat more slowly. Don't go grocery shopping when you're hungry. When you do go grocery shopping, don't buy lots of snacks in the first place and you'll never be tempted to eat them. Switch to 2% milk. Don't feel like you have to count calories, but do be aware of how many calories there are in the things that you buy.
Healthcare currently is costing America approximately 15% of GDP and getting poor results. A well-implemented national plan could bring that down into line with the other developed democracies of the world such as Germany and the U.K., or about 10% (your numbers may vary depending on calculation method, etc, and may be somewhat lower, but let's go with 10% for a rough estimate). This saves 5% of the current US economy that can be put to productive uses instead of pointless quality-of-life-diminishing health insurance bureaucracy.
You can't compare health care spending in the US to another country so naively. You are making the assumption here that you're "buying" the same thing in the US with that $1 that you are in other countries. A considerable amount of research and development of new life-extending technologies and procedures comes out of the US health care industry. Where do you think funding for that stuff comes from? If you want to simply lower spending, sure, that's an achievable goal, but be careful of what you wish for.
I didn't say everybody is an opportunistic douchebag, just that there will always be douchebags in the world, so it makes more sense to accept that fact and design "douchebag resistance" into everything that we build, rather than cry and try to weed them out later.
Botnets and financial data have value, so it makes sense that there's profit to be had in finding ways to infect new machines. These are the same douchebags that fill up my gmail Spam folder. If there's profit to be had, and nearly zero chance you'll be caught, people will do pretty much anything. It's human nature. All you can do is improve the sandbox so that people can't (profitably) abuse it, and most of the douchebags will leave.
Just do them right: 1. Each commit should have an explanation of what the change does, and should be small enough that the reviewer can do it quickly. 2. Your organization should prioritize code reviews over other work; in many cases the review is blocking something.
If your reviews are kept small, and are a high priority, they add enormous value and shouldn't negatively impact your work.
Code reviews have the following perhaps non-obvious benefits: - They ensure the implementation does justice to the design - They help pass institutional knowledge to the developer ("This function has an existing implementation over here...") - They ensure code readability (especially when used with a formal style guide) - They help keep the developer honest, when he or she might take shortcuts or be lazy with a certain function. - By mandating code reviews, you have a pressure from the reviewers to keep each commit small, which encourages incremental development, which discovers design flaws early rather than after 10,000 lines are written.
Code reviews aren't really a great place to FIND bugs. Yes, obvious bugs will stand out to an experienced developer, but the reviewer is another human, and he or she can easily miss the same bugs the developer missed. Really, unit tests are where you catch bugs, and a reviewer is usually in a better position to identify incomplete unit testing.
The cop neither has the intent to actually sell (drugs, his/her body), nor does the cop actually attempt to sell either of those things. For a cop to walk up to someone and say, "Hey, I'm a prostitute, would you like to buy my services?" is entrapment. The cops may passively mislead people into thinking they're selling, but at least until the victim/criminal solicits the sale, they can't offer or solicit anything.
As far as the "you... can be busted for lying to THEM, even if they do not identify themselves as a police officer," I'd need to see a citation. You can't be charged with lying to a police officer if the officer doesn't identify him/herself.
Simply using a cross-platform toolkit doesn't mean your ports are "for free". The sandboxing techniques used by Chrome, for instance, depend heavily upon the facilities provided by the OS. The UI toolkit is a very small part of the problem for some applications.
I guess someone should explain to Google about code and component reuse.
Fortunately this is easier to do in HTML5 with a plain <video> tag. YouTube has a sample page done up with HTML5, complete with moving thumbnails: http://www.youtube.com/html5
The solution is to devise & implement a fully distributed DNS system where the TLD's server in each country operate in a peering setup.
How would such a thing work? Who would decide on new gTLDs? Who would delegate control of gTLDs? What happens when one country disagrees with who got responsibility for some ccTLD?
While you could pretty easily come up with some sort of physical distributed root (and that's largely what we have today), you still have to get everyone to agree on what that root should point to, or you end up with fragmentation and different views of what should be the same tree. IMO, you need to keep politics out of the picture as much as you can, either by making this process owned by one country, or by an international standards organization. Distributing that authority to many countries directly opens the door for a lot of pain.
This isn't about helping Apple. It's about helping the local communities that would benefit from Apple building a massive datacenter there. Local people get hired to do the construction. Some get hired to operate it. Others relocate just to work there. These workers need housing, restaurants and retail. This is money that flows from Apple, to its employees and contractors, to your town's businesses, to your town's residents. If you want your local economy to improve, it's in your best interests to give companies like Apple an incentive to build in your town, instead of someone else's. This means things like tax breaks.
Companies avoided BPA because of the mass hysteria surrounding it, not because of any scientific studies that indicate BPA is actually harmful at the concentrations people are exposed to. This is neither a success of market forces nor better than a government mandate, IMO. The latter should be based on sound science, not mob panic.
You do, in fact, see a difference in your life when companies bend to this type of pressure. Either quality drops, or products get more expensive to produce, which means you get to pay more for stuff that isn't actually any safer.
I'm a huge supporter of the market economy, but this is one of the areas where it sucks (demand can change irrationally).
Sure, there's a distinction between plain searches, and AdWords. But there's more of a distinction between AdWords and a true keyword service (like AOL keywords). With a keyword service, you type in "microsoft", and you are sent to www.microsoft.com and nowhere else. Google's equivalent to AOL keywords is the "I'm Feeling Lucky" button. You don't see ads if you click that button.
I don't want AdWords to behave like a keyword service. If I'm doing a search for "microsoft", I may not want the first search result (www.microsoft.com). Maybe I want content about Microsoft, which means I need to look beyond the trademark, and possibly learn about competitors. Similarly, I want ad relevance to extend beyond the trademarks in my searches.
Further, you seem to be of the view that ads for a trademark have direct value to the trademark holder. If I search for "microsoft", chances are, an ad for "www.microsoft.com" is going to be essentially useless to me, since Microsoft will be the first search result. These types of ads have little value to the trademark holder, IMO, but there is value in prohibiting competitors from sticking ads on searches related to my trademark. But, again, so long as the ad isn't misleading users, I think it's fine. If an ad comes up and says, "Try Apple! We're better than Microsoft!" and doesn't claim to be an ad for Microsoft, I have nothing but support for that.
This should be about what I, the person doing the search, find relevant, not what the trademark holder thinks I should be shown. Restricting ads in response to searches related to trademarks doesn't benefit me, it hurts my ability to find relevant content. The only one that benefits is the trademark holder, and only because it's preventing competitors from getting non-misleading, relevant (else Google wouldn't continue to show them) ads for those keywords. If your business is so bad that you're losing customers because of someone else's ad, you should look at fixing your business, not stifling competition by preventing them from advertising to people seeking information about you (which ought to include your competition).
Or possibly because some of us think punitive taxes are an inappropriate use of government power, and only serve to distort the market?
But that's the whole point. A truly free market has serious flaws. If everyone agrees that raw material X is bad, and we need to reduce our consumption of it, merely talking about the drawbacks to X isn't going to have a serious impact on its consumption. If it's the cheapest alternative available, it's going to continue to find its way into products, and people will sheepishly continue to buy it.
You can regulate X directly, and say that companies can only consume a certain amount of X, but if X has alternatives for some uses, but no alternatives for other uses, you have to create complex legislation and a cap-and-trade system for those products to continue to exist. People that can switch from X to Y can do so with a modest increase in costs, but everyone else is going to be spending a lot of time and money finding loopholes and ways to continue consuming X as much as possible, to keep their costs low. You can combat that only with more, increasingly complex, regulation.
The alternative is to simply raise the price of X until consumption drops to the point where you want. Let the market decide how to decrease consumption. Those that can switch will jump at the chance to do so. Those that can't switch simply have higher costs, which means higher prices, which usually means lower demand, which means reduced consumption. You don't have loopholes to deal with, complex cap-and-trade systems, etc.
If you truly prize the market's ability to efficiently allocate resources, interference through taxation seems far preferable to interference through regulation. Either way, costs go up, but the mechanism behind it is far more straightforward when you just have taxation.
In my experience, they do try to contact you before shutting it off. In my case, though, I'm usually traveling when the red flags go up, so I always miss their attempts to contact me.
Slashdot Mirror
How do you know it wasn't encrypted and password-protected? You have to decrypt and provide a password to access an encrypted and password-protected volume, right? The problem here is that the moron had Limewire configured to scan for and share everything on his system, including the sensitive stuff. If he did this after he'd opened the encrypted volume, Limewire would have been able to access it like any other file.
Both of these are great reasons to populate your masters with your zone data out-of-band.
Dynamic updates become difficult if your masters get their data OOB, since they have no way of knowing how to propagate those updates back to the source. It just depends on your needs and your setup. For the majority (?) of configurations, having an inaccessible master doing zone transfers to exposed secondaries is perfectly reasonable. For more complex setups such as yours, it's not, but that design has its own set of costs.
You're absolutely right: a compromised server can't be trusted to give faithful replies, regardless of how bind has it configured. I think the recommendation to not run your primaries exposed is intended to protect the zone data itself, not the queries served by the machine (though, in theory, that's what DNSSEC is for). Many DNS configurations involve a single machine that acts as a DNS master, and on that machine are the only copies of the "live" zone files. If that machine gets compromised, it requires a fair bit of manual effort to recover the zone files from backups, replay any updates that needed to be made, and return to service.
In more complex setups (such as yours), the live zone files are not stored exclusively on the masters. They come from Somewhere Else (a config repository, LDAP, whatever), and you need some sort of out-of-band process to get the data to the DNS masters to be served. SSH/rsync/whatever are perfectly fine ways to do that OOB transfer. But for most setups, the simplistic configuration makes the most sense, especially if you have to deal with dynamic updates, where it may be difficult to propagate changes back to your config repository.
Which is essentially what I was trying to say: TSIG and SSH solve the same authentication problem, so if your source is a DNS server, and your destination is a DNS server, why reinvent zone transfers?
Run your network however you prefer! Just don't advocate for your design, and rail against more common configurations and their associated best practices, using reasons that do not support your arguments. You have valid reasons to run your systems the way that you do, so use them to justify your design, but be aware that they do not extend to cover other configurations.
DNS queries are not encrypted, so if you believe the contents of your DNS zones should be secret, you'd better hope nobody queries them. You may be interested in TSIG, which can authenticate your secondaries to your master. If you'd prefer to store and manage your zone files "offline", pushing them out to one or more masters through SSH or something might be the right thing to do, but if you already have an internal master, and need to update some public-facing slaves/shadow masters, there's no reason to re-invent DNS zone transfers.
So I'm responding not because I disagree with your conclusions, but I disagree with the logic you're using to justify them:
You start off with a reasonable statement (that you don't generally want compromised DNS servers to allow for the modification of data), but then you say bind9 is a piece of shit because it's a best practice that the masters (which hold the data) shouldn't be exposed to the public. Which is it?
Would you care to elaborate on that? Doesn't TSIG secure zone transfers? TSIG is just as easy to set up as SSH keys are.
How much more automated can you make automatic zone transfers? What better scheduling of zone transfers than when the zones are modified?
The only thing you need to open through the firewall is TCP and UDP port 53. Most firewalls make this easy, because "Serve DNS through the firewall" is a common configuration for firewalls.
SSH makes life easier for someone that understands SSH, and does not understand DNS or firewalls.
That being said, there are valid reasons you might not prefer to run a DNS master as the source for your slaves/shadow masters, and SSH might even be a good way to push your zone files out to those machines, but you have not provided any of those reasons.
What part of that phrase confuses you? He's talking about revenue. That he makes in the future. That is potential, because individual photographs might not license well in the future, but some percentage of his portfolio probably does. And that revenue would be lost if he gave away his rights. What's the problem?
I'm a bit baffled by this statement. I suspect you've misunderstood something I've written. I'm certainly not advocating "A or B, at the exclusion of everything else."
I think I understand now. You seem to think a spec is the place for you to force everyone to do what you want them to do (adopt a free video codec). You seem to be under the mistaken belief that the spec carries the force of law, or that some magical property of the spec will make browsers useless until they follow the spec. Every browser out there ignores something that's codified in a spec today. IE in particular does this quite a lot, yet it still has a clear majority in the browser market. Are you really suggesting that IE is useless? Or is it just useless to you?
I believe that a spec is the place to encourage interoperability. This means the spec must necessarily reflect reality, not a utopia. "Gosh, it would be nice if everyone did X, so let's prescribe X" is stupid if everyone is already doing Y, but it's smart if nobody is doing anything yet. If people have already decided what they're going to do, the spec should reflect that, not prescribe something entirely different. You can't achieve interoperability if you ignore reality, because people must ignore the parts of the spec that disagree with reality if they want interoperability. This makes (these parts of) the spec useless.
So, saying "at least H.264 or Ogg" is (IMO) better than saying "at least H.264" or "at least Ogg", because the latter two will disagree with reality, and will need to be ignored by implementers. But saying "at least H.264 or Ogg" is like saying "at least PNG or GIF", and we don't have that in the HTML standard either. If you wish your argument to be consistent, you should advocate for that as well (along with audio formats). I personally don't believe codecs and file formats are necessary for the HTML spec, for reasons I've already given (and for the same reason I find adding "at least GIF or PNG" silly).
But the converse is not necessarily true. Just because it isn't in the spec doesn't mean that web site authors do NOT know that H.264 or Ogg are the two codecs supported (individually) in all web browsers. This isn't like some ambiguity in HTML rendering here where there can be as many implementations as there are interpretations, in as many combinations as there are ambiguities and browsers. You can either choose to support a codec, or choose not to. Anyone in the position to be making such a decision is going to be intimately aware of the codec options that are out there, what other browsers support, and what web sites make available.
I'll turn the implication in my previous post into an outright question: Why haven't we standardized on "GIF OR PNG" in the HTML spec too? Do you believe that is necessary? If not, why <video> and not <img>?
A specification that is lacking is exactly as useless as a specification that is ignored. So long as companies feel they have a reason to avoid Ogg, it doesn't matter a bit whether or not the specification says Ogg must be supported. There is no law saying implementations must follow the spec. This is why I perceived your statement as flippant: there is more to the question of whether or not to implement Ogg than how "free" it is. You come across sounding like an open source fanboy when you suggest the solution to the problem is to use the "free" solution. "Like, OMG, duh!" Things aren't quite that simple.
I assume you're talking about leaving the codec question undefined? Wouldn't saying "H.264" or "H.264 OR OGG" in the specification potentially lead to this same result? Are you advocating for a more specific standard, or for Ogg specifically?
IANAL, but I suspect the intent of that provision is to permit them to prosecute when they have pictures of someone that is obviously a minor (a child in the physical sense). If someone has sexually-explicit pictures of someone that is very clearly ~12 years old, you shouldn't have to jump through hoops to identify this one person (which could be anywhere in the world), and prove their age. I don't think the intent is to allow them to point to a picture of a sexually-mature (but young) woman, say they're a minor, and prosecute you for having it, without actually proving that they're a minor. If there's a legitimate question of fact about whether the person is a minor, you'd have to get a really stupid or evil jury to let you get convicted for it.
Sure it could. It could also say "EITHER PNG OR GIF", but it doesn't. How much interoperability does this actually buy you? A de facto standard isn't all that different from a de jure one, and they made a point not to standardize on image formats, so maybe it's OK to let this one go too? IMO, this isn't as bad as people seem to be making it out to be. You already have an incentive to choose H.264 or Ogg, because if you're putting content out on the web, you probably want it to be viewable by as many people as possible. Standardizing on "A OR B" doesn't, IMO, improve the world in any measurable way.
This is a bit flippant and suggests that you don't understand the nature of the objections to using Ogg.
Did you read their reasons for avoiding H.264? If H.264 goes into the spec, who's going to pay the licensing costs for Opera to "conform" to the spec? Who's going to pay for the licenses of those that derive their own web browsers from Mozilla or Chromium sources? The reasons companies have for preferring NOT to implement a codec aren't necessarily technical.
We survived fine without explicit HTML standardization on JPEG, GIF and PNG. We'll be fine here too.
If the companies can't agree, a spec isn't going to make them agree. Everyone has their reasons for not implementing a codec. Putting a requirement into a spec isn't going to magically solve any of those concerns. It makes it slightly easier for some people to point their fingers and say "they're bad for not following the spec!!1" but it doesn't actually help solve any problems. If anything, it creates a new problem as people try to make their own implementations of the spec, only to discover that they don't interoperate with anyone else because everyone is ignoring that one little part of the spec. If your spec includes stuff that half of your implementers will ignore, deliberately, with full knowledge of the ramifications, then perhaps you should revisit your approach to the spec.
There's nothing that says this can't be revisited later. But for now, it's quite clear that implementers will not implement a common video codec. So what exactly is the point of mandating a common codec in the spec?
What does that even mean? Your resting metabolic rate is determined almost completely by what it is that you're powering: if you're fat and have larger organs, you need to burn more to support those systems. Two people with identical body types and activity levels will burn the same amount of calories.
The "regardless of how much or what I eat" sounds wrong and defeatist. If you truly believe what you're telling us, that there's just nothing you can do, and you'll always gain weight no matter what you try, then you're never going to get anywhere. Of course changing how much or what you eat will change how much weight you gain or lose.
This basic equation always holds true: If calories in is greater than calories burned, you gain weight. If calories in is less than calories burned, you lose weight. That's all there is to it. Balance the two however you want.
A can of soda has ~150 calories. Running 1.5 miles will burn ~150 calories. It's far easier to forego that can of soda and drink some water instead, than it is to commit to a 20-minute jog, yes? Both will have the same impact on your weight. The latter, though, will improve your health in other ways. So if you simply can't find time to exercise and increase the number of calories you burn, focus instead on decreasing the number of calories you consume.
If you have a weakness for food, such that you feel you have to "fill up" all the time to curb your hunger, look at the energy density of the foods you eat. Avoid foods that are energy-dense (fried foods, sweets, sodas, processed foods) and start buying foods that have less energy for the same volume, like fruits and vegetables, and anything with a high water content. Drink a glass of water before every meal. Eat more slowly. Don't go grocery shopping when you're hungry. When you do go grocery shopping, don't buy lots of snacks in the first place and you'll never be tempted to eat them. Switch to 2% milk. Don't feel like you have to count calories, but do be aware of how many calories there are in the things that you buy.
You can't compare health care spending in the US to another country so naively. You are making the assumption here that you're "buying" the same thing in the US with that $1 that you are in other countries. A considerable amount of research and development of new life-extending technologies and procedures comes out of the US health care industry. Where do you think funding for that stuff comes from? If you want to simply lower spending, sure, that's an achievable goal, but be careful of what you wish for.
I didn't say everybody is an opportunistic douchebag, just that there will always be douchebags in the world, so it makes more sense to accept that fact and design "douchebag resistance" into everything that we build, rather than cry and try to weed them out later.
Botnets and financial data have value, so it makes sense that there's profit to be had in finding ways to infect new machines. These are the same douchebags that fill up my gmail Spam folder. If there's profit to be had, and nearly zero chance you'll be caught, people will do pretty much anything. It's human nature. All you can do is improve the sandbox so that people can't (profitably) abuse it, and most of the douchebags will leave.
Just do them right:
1. Each commit should have an explanation of what the change does, and should be small enough that the reviewer can do it quickly.
2. Your organization should prioritize code reviews over other work; in many cases the review is blocking something.
If your reviews are kept small, and are a high priority, they add enormous value and shouldn't negatively impact your work.
Code reviews have the following perhaps non-obvious benefits:
- They ensure the implementation does justice to the design
- They help pass institutional knowledge to the developer ("This function has an existing implementation over here...")
- They ensure code readability (especially when used with a formal style guide)
- They help keep the developer honest, when he or she might take shortcuts or be lazy with a certain function.
- By mandating code reviews, you have a pressure from the reviewers to keep each commit small, which encourages incremental development, which discovers design flaws early rather than after 10,000 lines are written.
Code reviews aren't really a great place to FIND bugs. Yes, obvious bugs will stand out to an experienced developer, but the reviewer is another human, and he or she can easily miss the same bugs the developer missed. Really, unit tests are where you catch bugs, and a reviewer is usually in a better position to identify incomplete unit testing.
The cop neither has the intent to actually sell (drugs, his/her body), nor does the cop actually attempt to sell either of those things. For a cop to walk up to someone and say, "Hey, I'm a prostitute, would you like to buy my services?" is entrapment. The cops may passively mislead people into thinking they're selling, but at least until the victim/criminal solicits the sale, they can't offer or solicit anything.
As far as the "you ... can be busted for lying to THEM, even if they do not identify themselves as a police officer," I'd need to see a citation. You can't be charged with lying to a police officer if the officer doesn't identify him/herself.
Simply using a cross-platform toolkit doesn't mean your ports are "for free". The sandboxing techniques used by Chrome, for instance, depend heavily upon the facilities provided by the OS. The UI toolkit is a very small part of the problem for some applications.
Clearly, they need your help!
Fortunately this is easier to do in HTML5 with a plain <video> tag. YouTube has a sample page done up with HTML5, complete with moving thumbnails: http://www.youtube.com/html5
How would such a thing work? Who would decide on new gTLDs? Who would delegate control of gTLDs? What happens when one country disagrees with who got responsibility for some ccTLD?
While you could pretty easily come up with some sort of physical distributed root (and that's largely what we have today), you still have to get everyone to agree on what that root should point to, or you end up with fragmentation and different views of what should be the same tree. IMO, you need to keep politics out of the picture as much as you can, either by making this process owned by one country, or by an international standards organization. Distributing that authority to many countries directly opens the door for a lot of pain.
This isn't about helping Apple. It's about helping the local communities that would benefit from Apple building a massive datacenter there. Local people get hired to do the construction. Some get hired to operate it. Others relocate just to work there. These workers need housing, restaurants and retail. This is money that flows from Apple, to its employees and contractors, to your town's businesses, to your town's residents. If you want your local economy to improve, it's in your best interests to give companies like Apple an incentive to build in your town, instead of someone else's. This means things like tax breaks.
Companies avoided BPA because of the mass hysteria surrounding it, not because of any scientific studies that indicate BPA is actually harmful at the concentrations people are exposed to. This is neither a success of market forces nor better than a government mandate, IMO. The latter should be based on sound science, not mob panic.
You do, in fact, see a difference in your life when companies bend to this type of pressure. Either quality drops, or products get more expensive to produce, which means you get to pay more for stuff that isn't actually any safer.
I'm a huge supporter of the market economy, but this is one of the areas where it sucks (demand can change irrationally).
Sure, there's a distinction between plain searches, and AdWords. But there's more of a distinction between AdWords and a true keyword service (like AOL keywords). With a keyword service, you type in "microsoft", and you are sent to www.microsoft.com and nowhere else. Google's equivalent to AOL keywords is the "I'm Feeling Lucky" button. You don't see ads if you click that button.
I don't want AdWords to behave like a keyword service. If I'm doing a search for "microsoft", I may not want the first search result (www.microsoft.com). Maybe I want content about Microsoft, which means I need to look beyond the trademark, and possibly learn about competitors. Similarly, I want ad relevance to extend beyond the trademarks in my searches.
Further, you seem to be of the view that ads for a trademark have direct value to the trademark holder. If I search for "microsoft", chances are, an ad for "www.microsoft.com" is going to be essentially useless to me, since Microsoft will be the first search result. These types of ads have little value to the trademark holder, IMO, but there is value in prohibiting competitors from sticking ads on searches related to my trademark. But, again, so long as the ad isn't misleading users, I think it's fine. If an ad comes up and says, "Try Apple! We're better than Microsoft!" and doesn't claim to be an ad for Microsoft, I have nothing but support for that.
This should be about what I, the person doing the search, find relevant, not what the trademark holder thinks I should be shown. Restricting ads in response to searches related to trademarks doesn't benefit me, it hurts my ability to find relevant content. The only one that benefits is the trademark holder, and only because it's preventing competitors from getting non-misleading, relevant (else Google wouldn't continue to show them) ads for those keywords. If your business is so bad that you're losing customers because of someone else's ad, you should look at fixing your business, not stifling competition by preventing them from advertising to people seeking information about you (which ought to include your competition).
But that's the whole point. A truly free market has serious flaws. If everyone agrees that raw material X is bad, and we need to reduce our consumption of it, merely talking about the drawbacks to X isn't going to have a serious impact on its consumption. If it's the cheapest alternative available, it's going to continue to find its way into products, and people will sheepishly continue to buy it.
You can regulate X directly, and say that companies can only consume a certain amount of X, but if X has alternatives for some uses, but no alternatives for other uses, you have to create complex legislation and a cap-and-trade system for those products to continue to exist. People that can switch from X to Y can do so with a modest increase in costs, but everyone else is going to be spending a lot of time and money finding loopholes and ways to continue consuming X as much as possible, to keep their costs low. You can combat that only with more, increasingly complex, regulation.
The alternative is to simply raise the price of X until consumption drops to the point where you want. Let the market decide how to decrease consumption. Those that can switch will jump at the chance to do so. Those that can't switch simply have higher costs, which means higher prices, which usually means lower demand, which means reduced consumption. You don't have loopholes to deal with, complex cap-and-trade systems, etc.
If you truly prize the market's ability to efficiently allocate resources, interference through taxation seems far preferable to interference through regulation. Either way, costs go up, but the mechanism behind it is far more straightforward when you just have taxation.
In my experience, they do try to contact you before shutting it off. In my case, though, I'm usually traveling when the red flags go up, so I always miss their attempts to contact me.