While I agree that mocking other people's taste in music is pathetic and contributes nothing (other than to remind all readers that the mocker is completely unable to accept that other people might have different tastes to themselves)... the grandparent was committing the exact same sin by saying that there was only one band they'd consider seeing and therefore implying that there was no reason for anyone to want to go to such a festival.
So, two posts in a row that were just noise and added nothing of interest to anyone. Arguably, it's now four...
There's a lot of things that can go wrong that we'll have no control over, no matter how eco-friendly we manage to become.
Of course, it's inevitable we'll end up living on more than one rock when we have capability to do so, so I'm not sure the point of this. Obviously any single planet is going to be uninhabitable given enough time.
True, it's an unusual network configuration to be "exposed by default"; however I still haven't seen any rational explanation why "listen on all interfaces" is a better default than "listen only on loopback".
If you're that oblivious, how the hell is making you fill out a config file going to help you?
Because the config file section that needs to be modified has comments explaining the risk? Not everyone is going to go and read external documentation on a piece of software before installing it. If you're going to do that, why even use a distribution in the first place? Any documentation you read is likely to be helpful, but may refer to paths that are different because the maintainer for your distro's version of the software has changed it; or may be for a different version; or may not have certain patches applied; and may very likely have a different default configuration.
It's very common for people's first real exposure to the configuration of a piece of a software to come after having installed it from their distribution's repository. It makes sense for that initial configuration to be as conservative as it can reasonably be made, and to guide the administrator through the correct configuration of it to meet their needs.
It could well be a cultural thing though; perhaps it's normal for Gentoo to install services so that they're configured to listen on all interfaces by default. If you install PostgreSQL or MySQL, can you then immediately connect to them from an external host? If you install squid does it default to proxying traffic for your local network? If so, then perhaps the behaviour of memcached is entirely expected; but I still think it's a sub-optimal default that carries some risk for little or no benefit.
Yes. It's also interesting that their response to the high piracy rate is to lower the price of the product.
The implication here is that the initial price was too high. They started out at $20, but who's to say the game has $20 worth of value? They face the same problem all other entertainment faces: how can you know the value of the entertainment until you've experienced it? If I play the demo, will I decide the full game is worth $20? How can I possibly know that? Lowering the price improves the odds that the gamble will pay off, i.e. it will be worth the money. Several people in the comments for the story have already said they'd never heard of the game, and having looked at it wouldn't pay $20 for it, but are picking it up for $5. $20 isn't a huge amount of money, but I think there's a significant psychological effect here. Five bucks is well within the realm of casual impulse buying. Twenty is stretching it a bit.
More interesting to me is their methodology for determining the piracy rate. I didn't see any indication of that. I also didn't see any comparison to other titles (with DRM) which have similar exposure and potential audiences. Big-budget titles with massive advertising campaigns probably have a lower piracy rate, because casual gamers (who don't know how to download things) are more likely to buy them; it's hard for a small developer to reach that kind of audience though. Even so, comparison to similar style games from big publishers would be interesting. 90% sounds like a horrible ratio, but if the industry average is 85% and these guys didn't have to pay anything for DRM and associated support costs, then maybe it's actually a win.
Another issue is online sales. While I personally "only" buy things online, in the game forums I'm active in there's always people who are only interested in the box version and will not, or cannot, buy the game online. I'm sure a lot of the people who pirated the game had no intention of ever buying it; not because of the amount of money, but because they're afraid or unwilling to buy digital goods.
I think that in your rush to rebuke the parent with scathing sarcasm, you have misinterpreted their point. I don't see anyone suggesting the software should install in a secure, perfectly functional manner, with no configuration whatsoever. The only quote I saw was saying that it's preferable for the software to be installed without a working configuration, so the administrator must explicitly configure it for their purposes. If they fail to configure it securely in the process, that's their own failing. What software shouldn't do is install a configuration which is "insecure by default" but actually functional, as this encourages (or at least, permits) clueless admins from installing it, testing it to see if it works for their own purposes, and then forgetting about it. This appears to gel perfectly well with your philosophy, i.e. it's the system administrator's responsibility to ensure their system is configurable correctly and securely.
The Gentoo example appears to install a functional but insecure configuration by default. If the user simply starts the service (or possibly reboots the server without doing further configuration and it auto-starts at the next boot), then tests their application, they will be overjoyed that it's working and move on to their next task. The admin may not be aware that memcached is not designed to be exposed directly to the internet. Or, they may doing a small install with the web server being on the same machine, and it may never even occur to them that the software might be listening on all network interfaces (given they've configured their web application to talk it to via loopback). Or, they may have simply had a momentary lapse in concentration and forgotten about it. People are fallible, after all.
The Debian default install, on the other hand, is reasonably safe against human forgetfulness. If they're only configuring a local instance, then the configuration will work and they'll move on like in the Gentoo example - but without having the service unintentionally exposed to all network interfaces. If they're configuring it to be network-accessible, then they have to modify the configuration, and therefore received a reminder that they need to take steps to protect the service.
I imagine this would be part of the buyout proposal if it matters to the purchasing company. You'd have to notify every employee and have them agree to terms of employment with the new owner (which may just be the same terms, but not necessarily). I mean, you can't force people to work at a certain place, so you'd have to new contracts set up to retain the employees. Of course that means you have to spend longer in negotiations with more people knowing details of the deal, which increases the likelihood of leaks.
The IP isn't necessarily worthless if everyone leaves though. Generally all rights to the software developed by the employees of a company are owned by the company, so the buyer would get those. They would of course lose the knowledge from the people who wrote it/worked on it; but depending on how many leave and how complex the software is (and what kind of state the codebase is in), it's quite feasible to have others take over. Especially if you already have programmers etc. in a related field.
Again, all this stuff should be spelled out in the buyout proposal, including whether the buying company actually gets rights to the source code or just the trademarks, etc. Maybe not initially, but during the negotiations certainly. You're not going to buy another company without all the details pertaining to exactly what you're getting being agreed to in writing. Unless you're an idiot, of course. Although sometimes you might just be killing of a competitor, so loss of knowledge etc. isn't a problem -- you don't plan to do anything with it anyway, except bury it.
Hmm, you're also assuming they will have "spare" pilots in the hub cities ready-to-go at a moment's notice. And that the spare aircraft will always be ready-to-go at short notice, too. I'm sure there's significant costs associated with both of these. Even an idle airframe needs inspection before you can be sure it's safe to fly (and all the avionics, etc.). Then there's parking fees at airports, which are going to be pretty significant. So there's more costs involved than merely purchasing an extra couple of planes.
Fares may be in the hundreds of dollars, but flying a jet costs a lot more than running a bus.
Additionally, we're talking $50 million dollars plus to buy a 737, which is apparently most or all of Southwest's fleet (unusual for an airline - most would also have to grapple with the logistics of having multiple types of spare plane). And even assuming every ticket costs $500 and ALL of that goes to the airline as profit, you need to make 729 flights before you've paid off the initial investment. Assuming that there's no maintenance and staff and fuel costs, and that you bought the cheapest version of the plane. Clearly, the actual profit is nowhere near 100%.
Assuming a 10% profit margin on that $500 ticket (which seems awfully expensive and way more than your average one-way ticket is going to cost) - that's 1,000,000 tickets to pay for that $50 million plane, which works out to 7,299 fully-booked flights. At 7 flights per day, an aircraft will take 1,042 days to pay for itself. Assuming it's actually carrying full-fare paying passengers, and not sitting in a hangar somewhere.
So, I agree with your assessment that this would have to be mandated by the government. But I don't think most people would be willing to pay more for a ticket just for reducing the chance of a delayed/canceled flight. Because if they were, airlines would already be offering this to give themselves a competitive advantage.
Btw, your $5 extra per ticket, assuming it goes entirely to paying for the $50 million spare plane, would require nearly 73,000 fully-booked flights in order to pay off a single spare plane. If a plane makes 7 flights per day, they can recoup the costs for a single "spare" plane in a mere 28 plane-years!
Your previous posts suggested that the one-party system simplified everything, and then when I asked on corner cases (based entirely on things that you introduced to the discussion), you said it's all basic logic and "this is not hard to understand", as if I was an idiot for not being able to immediately grasp the world's simplest law and all its implications that come about through basic logic.
Now you're saying it's just as complicated as any other law, and this suggests to me that the claim present in this thread's subject -- "The problem is Maryland's two-party law" -- is perhaps erroneous. Perhaps the problem is more that Maryland's officials seem to think that videotaping a police officer in a public place carrying out official duties is an infringement of privacy. I'm pretty sure even if they had a one-party law, they'd be able to find some other reason to throw the book at the accused.
It certainly doesn't help to have laws prohibiting people from doing things they ought to be allowed to do; but with such a complicated legal system, it's almost guaranteed that in any given situation there's some law that could be used. There's no reason they had to prosecute this guy under wiretapping laws; they did it because they wanted to suppress criticism of the conduct of police officers. (I'm not entirely sure they've succeeded in that goal.)
Or to put it more simply: if Maryland was a one-party state, would this guy still have been charged -- just with something else? I don't have access to any alternate realities myself, but I don't think it's a bold claim to suggest that they simply went after him with whatever they had available, and changing this particular law probably wouldn't have solved anything. The problem is more one of a culture of bullying and intimidation.
Fair enough; though I don't think the basic logic extends very well to having cameras in your house. What if I park my car somewhere and leave a camera recording whatever's out the window, is that okay?
If it is, then: a camera is something you own, so surely I'm entitled to record anything that's where the camera is?
It also doesn't address things I can e.g. see from my house. Can I put a camera on a tree in a house that happens to have a good view of the neighbour's bathroom or bedroom or whatever?
I don't understand why it's okay to covertly film a gang banger beating the crap out of someone in a "one party system". Neither of the involved parties are aware they're being recorded. If the argument is that the person filming it is involved by virtue of the fact that they're filming it, then why aren't then they allowed to sneak a camera into your neighbour's house to record them? I mean, you're still aware that they're being recorded. I don't see how your lack of physical presence means anything, because in the former case (gang banger) nobody involved was aware of your presence then, either.
Is it not that the one-party system prevents it, but because you need to break other laws (e.g. trespass) in order to do it?
But I still don't see why it's okay to film people without their consent under one-party, but not under two-party, unless you're one of the involved parties.
How can a Flash app be design to allow for search?
By putting most of the content in searchable formats (probably XML), and probably by following some kind of standards. I mean, Flash apps can be made accessible too, but most developers don't bother. Plus, a well-designed site can have a simple version that can easily be indexed (using e.g. the sitemap XML for search engines) and a "rich" version which might be harder to index. So it's a problem that can be solved in multiple ways. At worst, the.swf could be decoded, and any text blobs within it parsed.
But my point was, sites need search engine traffic more than the search engine needs the site. Yes both are dependent on the other, but unless a great big chunk of the web moves en masse, they'd only be hurting themselves (unless they're in some kind of niche where they don't care about search engine traffic). Or in other words, the onus isn't on Google to find a way to index their site, but on the site owners to make sure that whatever they do, they're still in Google. If a big site blocks a search engine from indexing it (whether via Flash or Java or robots.txt) then other sites will be more than happy to take the extra traffic.
Not if the Flash is well-designed, and if it's not well-designed then the site using it will lose ranking in the search engines. I don't think Google really needs to go out of its way to index content nowadays, as if you're not in Google then you don't exist for a lot of the web's users...
Firstly, the people spending their time breaking the copy protection are the ones already doing that. It's not something you'd have to do yourself.
Secondly, it's pretty interesting that you say you're willing to pay for a product that "just works" without having to faff around. Because that is actually a large incentive for people to pirate games and other software: the pirated version just works. If you buy it then you have to at best keep track of a license key; at worst, you have to activate it online (hoping their activation servers are working at that time), maybe even have to be connected to the internet every time you run it, potentially run out of activations if you change computers a lot or they have a low limit to start with (and then you have to contact their support asking for more activations for something you supposedly "own").
So with this model, you get to periodically buy new content from them. You have to hope they have sufficient bandwidth to deal with the surge of customers also buying the updated content. You have to hope their payment system doesn't have any problems -- not to mention that many of Codemaster's target market probably don't have credit cards or an easy way to make online payments in the first place. Then you have to hope their copy-protection system recognises your right to play the new content, etc.
The pirate on the other hand downloads a complete, working game with all the added content likely built-in; or if they're getting the content later the activation stuff will be removed. So it will in fact "just work". They aren't dependent on some company keeping their authentication servers running, or having enough bandwidth for the initial rush when new content is first released.
Additionally, there are still a lot of people who refuse to buy things online, which I think is going to make things interesting for companies basing their business model on DLC. I see this a lot on various game forums I visit.
(A customer is wondering why her anti-virus is asking her to purchase the program.)
Me: "What is the name of your anti-virus?"
Customer: "It is [name of a well-known fake anti-virus program]."
Me: "Ma'am, that is a fake anti-virus. Do not purchase that program because it will not protect your computer."
Customer: "No! Why do you want me to disable my anti-virus? I will not get rid of it! It's keeping my computer safe! I already purchased it three times and it still wants me to pay again! All I want to know is how to stop it from asking me to pay!"
If your "server daemon" enters an infinite loop, then it's definitely a bug. Of course you want it to be shut down cleanly sometimes, which means it has to have some mechanism for ending the loop, cleanly ending any current sessions, and releasing resources.
Which is interesting way of saying that Google is, to some small extent, profiting from providing links to sites that enable copyright-infringement. That is to say, Google would prefer not to remove these sites from their index because if they do, people looking for that stuff will use a different search engine -- thus reducing traffic to Google, which reduces their appeal to advertisers.
And the point I was making was that if they do that, then you don't simply risk having machines unpatched against a known and actively exploited vulnerability for up to a month, but you pretty much guarantee it. Your stance assumes that a vulnerability that has been privately reported is not only likely to be being actively exploited already, but is also likely to be being exploited against a sufficiently large number of machines so as to be a concern for the majority (or even a significant minority) of users.
Whether or not this is true is largely guesswork, but there are lots of security firms who monitor for unusual traffic patterns and any vulnerability that is being widely exploited tends to be picked up. If we trust the methods they use for collecting data on wild exploits, then it currently appears that they neither assumption is true.
As you say, it takes time to test patches, so there is an unavoidable window during which the fix will be published and widely available but not yet deployed to machines, putting them at very high risk (because anyone who wants to can create a tool to exploit the vulnerability). This will occur whether you immediately release the patch or wait. If you know exactly when the patches are coming out (even if you don't know what they're for) then you can plan around testing them at a particular time, thus reducing that window of maximum exposure as much as possible. If patches are issued as soon as they're ready, then the people doing the testing need to drop all their other activities on the floor at a moment's notice in order to get it out ASAP. That's usually not practical, as the people doing the testing have other tasks that they need to perform.
The point is they'll likely set aside a particular day each month or fortnight or week for testing patches. It's much easier to run a test against a bunch of updates all at once than against every individual update. Additionally, it's not only large companies that want to be able to test patches before pushing them out. Most companies don't have the resources to do patch testing at all (or more accurately: the cost/benefit ratio doesn't work out as it's easier to just fight the fire afterwards on the rare occasion a patch does break something) but some companies do need to, and not all have resources to have staff available to test the patches whenever they are released, but instead have scheduled times when they can do that.
So the idea is to minimise the time window between "everyone-and-his-dog being able to exploit the vulnerability" and "patch deployed to all machines". It is guesswork, of course. But basically: if the vulnerability isn't being actively exploited then it's not really a threat, just like the hundreds of other vulnerabilities that exist in your software right now which nobody has discovered. If you publish a patch to fix it for the use of the general public, then absolutely everyone with an interest in exploiting machines can easily determine how to take advantage of the vulnerability in any machine which isn't yet patched. So the time window between releasing the fix and having the patch installed is arguably the point where you're most vulnerable to it.
And it doesn't really matter if a handful of people know about the exploit. The likelihood of any one random blackhat attacking YOUR infrastructure is very small. But the bigger the pool of random blackhats grows, the more significant that very small likelihood becomes.
I mean, the sin has already been committed in that there's a vulnerability that can be exploited. There is no perfect fix for it, just like there's no way to "make it right" after you accidentally kill somebody. All you can do as a vendor is play the statistics and do whatever you can to maximise the % who don't get compromised by the vulnerability. As an end-user, all you can do is try to maximise the likelihood of you being in the % who don't get compromised.
Well they do have a tool to allow corporations to decide when to push patches - WSUS. And any organisation large or savvy enough to be testing patches before deploying them to workstations is going to be using it.
I think the reason for the Patch Tuesday release is to avoid disclosing the vulnerability to all and sundry. Otherwise, if the company doesn't want/to cannot test and deploy patches whenever they get released, there's going to be a period of time during which they have a vulnerability which is not only known, but attackers have the fix for it and can determine exactly what was changed to close it, thus making it very easy to generate an exploit for it.
Microsoft do occasionally release out-of-cycle patches for severe issues that are being actively exploited, so it's not as if they stick rigidly to the cycle even when it's clearly doing more harm than good.
The beer was still sold on a day when it's not permitted to sell it, and thus the law was broken. Just because you can get away with breaking the law doesn't mean the action is legal.
Look at this way: what if a police officer had happened to be in the store at the same time and witnessed it?
Option a) the shopkeeper doesn't attempt to stop the transaction, and gets charged with violating the law prohibiting the sale of alcohol on a Sunday.
Option b) the shopkeeper tells the woman she can't buy that, and she walks out with the beer regardless. She gets charged with theft.
There is also the possibility of option c) the police officer doesn't bother to enforce a law he sees as pointless. In which case, he potentially gets charged with whatever it is police officers are charged with when they fail to uphold the law.
Well the corporate filesystem itself has shadow copy so if we need to restore anything from the last 2 weeks or so it's right there in the 'previous versions' context menu. Users can even do it themselves - can't beat that for convenience. There's around 3 TB of local storage on the backup server which goes over to databases, email, system state, virtual machine images, and probably some other things I've forgotten.
The filesystem is about 1.5 TB and that goes right to tape. No sense using the local storage for backing that up when it's already checkpointed several times a day.
While I agree that mocking other people's taste in music is pathetic and contributes nothing (other than to remind all readers that the mocker is completely unable to accept that other people might have different tastes to themselves)... the grandparent was committing the exact same sin by saying that there was only one band they'd consider seeing and therefore implying that there was no reason for anyone to want to go to such a festival.
So, two posts in a row that were just noise and added nothing of interest to anyone. Arguably, it's now four...
There's a lot of things that can go wrong that we'll have no control over, no matter how eco-friendly we manage to become.
Of course, it's inevitable we'll end up living on more than one rock when we have capability to do so, so I'm not sure the point of this. Obviously any single planet is going to be uninhabitable given enough time.
True, it's an unusual network configuration to be "exposed by default"; however I still haven't seen any rational explanation why "listen on all interfaces" is a better default than "listen only on loopback".
If you're that oblivious, how the hell is making you fill out a config file going to help you?
Because the config file section that needs to be modified has comments explaining the risk? Not everyone is going to go and read external documentation on a piece of software before installing it. If you're going to do that, why even use a distribution in the first place? Any documentation you read is likely to be helpful, but may refer to paths that are different because the maintainer for your distro's version of the software has changed it; or may be for a different version; or may not have certain patches applied; and may very likely have a different default configuration.
It's very common for people's first real exposure to the configuration of a piece of a software to come after having installed it from their distribution's repository. It makes sense for that initial configuration to be as conservative as it can reasonably be made, and to guide the administrator through the correct configuration of it to meet their needs.
It could well be a cultural thing though; perhaps it's normal for Gentoo to install services so that they're configured to listen on all interfaces by default. If you install PostgreSQL or MySQL, can you then immediately connect to them from an external host? If you install squid does it default to proxying traffic for your local network? If so, then perhaps the behaviour of memcached is entirely expected; but I still think it's a sub-optimal default that carries some risk for little or no benefit.
Yes. It's also interesting that their response to the high piracy rate is to lower the price of the product.
The implication here is that the initial price was too high. They started out at $20, but who's to say the game has $20 worth of value? They face the same problem all other entertainment faces: how can you know the value of the entertainment until you've experienced it? If I play the demo, will I decide the full game is worth $20? How can I possibly know that? Lowering the price improves the odds that the gamble will pay off, i.e. it will be worth the money. Several people in the comments for the story have already said they'd never heard of the game, and having looked at it wouldn't pay $20 for it, but are picking it up for $5. $20 isn't a huge amount of money, but I think there's a significant psychological effect here. Five bucks is well within the realm of casual impulse buying. Twenty is stretching it a bit.
More interesting to me is their methodology for determining the piracy rate. I didn't see any indication of that. I also didn't see any comparison to other titles (with DRM) which have similar exposure and potential audiences. Big-budget titles with massive advertising campaigns probably have a lower piracy rate, because casual gamers (who don't know how to download things) are more likely to buy them; it's hard for a small developer to reach that kind of audience though. Even so, comparison to similar style games from big publishers would be interesting. 90% sounds like a horrible ratio, but if the industry average is 85% and these guys didn't have to pay anything for DRM and associated support costs, then maybe it's actually a win.
Another issue is online sales. While I personally "only" buy things online, in the game forums I'm active in there's always people who are only interested in the box version and will not, or cannot, buy the game online. I'm sure a lot of the people who pirated the game had no intention of ever buying it; not because of the amount of money, but because they're afraid or unwilling to buy digital goods.
I think that in your rush to rebuke the parent with scathing sarcasm, you have misinterpreted their point. I don't see anyone suggesting the software should install in a secure, perfectly functional manner, with no configuration whatsoever. The only quote I saw was saying that it's preferable for the software to be installed without a working configuration, so the administrator must explicitly configure it for their purposes. If they fail to configure it securely in the process, that's their own failing. What software shouldn't do is install a configuration which is "insecure by default" but actually functional, as this encourages (or at least, permits) clueless admins from installing it, testing it to see if it works for their own purposes, and then forgetting about it. This appears to gel perfectly well with your philosophy, i.e. it's the system administrator's responsibility to ensure their system is configurable correctly and securely.
The Gentoo example appears to install a functional but insecure configuration by default. If the user simply starts the service (or possibly reboots the server without doing further configuration and it auto-starts at the next boot), then tests their application, they will be overjoyed that it's working and move on to their next task. The admin may not be aware that memcached is not designed to be exposed directly to the internet. Or, they may doing a small install with the web server being on the same machine, and it may never even occur to them that the software might be listening on all network interfaces (given they've configured their web application to talk it to via loopback). Or, they may have simply had a momentary lapse in concentration and forgotten about it. People are fallible, after all.
The Debian default install, on the other hand, is reasonably safe against human forgetfulness. If they're only configuring a local instance, then the configuration will work and they'll move on like in the Gentoo example - but without having the service unintentionally exposed to all network interfaces. If they're configuring it to be network-accessible, then they have to modify the configuration, and therefore received a reminder that they need to take steps to protect the service.
I have mod points, but the +1 troll modifier seems to be missing.
Steam games can be played offline.
I imagine this would be part of the buyout proposal if it matters to the purchasing company. You'd have to notify every employee and have them agree to terms of employment with the new owner (which may just be the same terms, but not necessarily). I mean, you can't force people to work at a certain place, so you'd have to new contracts set up to retain the employees. Of course that means you have to spend longer in negotiations with more people knowing details of the deal, which increases the likelihood of leaks.
The IP isn't necessarily worthless if everyone leaves though. Generally all rights to the software developed by the employees of a company are owned by the company, so the buyer would get those. They would of course lose the knowledge from the people who wrote it/worked on it; but depending on how many leave and how complex the software is (and what kind of state the codebase is in), it's quite feasible to have others take over. Especially if you already have programmers etc. in a related field.
Again, all this stuff should be spelled out in the buyout proposal, including whether the buying company actually gets rights to the source code or just the trademarks, etc. Maybe not initially, but during the negotiations certainly. You're not going to buy another company without all the details pertaining to exactly what you're getting being agreed to in writing. Unless you're an idiot, of course. Although sometimes you might just be killing of a competitor, so loss of knowledge etc. isn't a problem -- you don't plan to do anything with it anyway, except bury it.
Hmm, you're also assuming they will have "spare" pilots in the hub cities ready-to-go at a moment's notice. And that the spare aircraft will always be ready-to-go at short notice, too. I'm sure there's significant costs associated with both of these. Even an idle airframe needs inspection before you can be sure it's safe to fly (and all the avionics, etc.). Then there's parking fees at airports, which are going to be pretty significant. So there's more costs involved than merely purchasing an extra couple of planes.
Fares may be in the hundreds of dollars, but flying a jet costs a lot more than running a bus.
Additionally, we're talking $50 million dollars plus to buy a 737, which is apparently most or all of Southwest's fleet (unusual for an airline - most would also have to grapple with the logistics of having multiple types of spare plane). And even assuming every ticket costs $500 and ALL of that goes to the airline as profit, you need to make 729 flights before you've paid off the initial investment. Assuming that there's no maintenance and staff and fuel costs, and that you bought the cheapest version of the plane. Clearly, the actual profit is nowhere near 100%.
Assuming a 10% profit margin on that $500 ticket (which seems awfully expensive and way more than your average one-way ticket is going to cost) - that's 1,000,000 tickets to pay for that $50 million plane, which works out to 7,299 fully-booked flights. At 7 flights per day, an aircraft will take 1,042 days to pay for itself. Assuming it's actually carrying full-fare paying passengers, and not sitting in a hangar somewhere.
So, I agree with your assessment that this would have to be mandated by the government. But I don't think most people would be willing to pay more for a ticket just for reducing the chance of a delayed/canceled flight. Because if they were, airlines would already be offering this to give themselves a competitive advantage.
Btw, your $5 extra per ticket, assuming it goes entirely to paying for the $50 million spare plane, would require nearly 73,000 fully-booked flights in order to pay off a single spare plane. If a plane makes 7 flights per day, they can recoup the costs for a single "spare" plane in a mere 28 plane-years!
Your previous posts suggested that the one-party system simplified everything, and then when I asked on corner cases (based entirely on things that you introduced to the discussion), you said it's all basic logic and "this is not hard to understand", as if I was an idiot for not being able to immediately grasp the world's simplest law and all its implications that come about through basic logic.
Now you're saying it's just as complicated as any other law, and this suggests to me that the claim present in this thread's subject -- "The problem is Maryland's two-party law" -- is perhaps erroneous. Perhaps the problem is more that Maryland's officials seem to think that videotaping a police officer in a public place carrying out official duties is an infringement of privacy. I'm pretty sure even if they had a one-party law, they'd be able to find some other reason to throw the book at the accused.
It certainly doesn't help to have laws prohibiting people from doing things they ought to be allowed to do; but with such a complicated legal system, it's almost guaranteed that in any given situation there's some law that could be used. There's no reason they had to prosecute this guy under wiretapping laws; they did it because they wanted to suppress criticism of the conduct of police officers. (I'm not entirely sure they've succeeded in that goal.)
Or to put it more simply: if Maryland was a one-party state, would this guy still have been charged -- just with something else? I don't have access to any alternate realities myself, but I don't think it's a bold claim to suggest that they simply went after him with whatever they had available, and changing this particular law probably wouldn't have solved anything. The problem is more one of a culture of bullying and intimidation.
Fair enough; though I don't think the basic logic extends very well to having cameras in your house. What if I park my car somewhere and leave a camera recording whatever's out the window, is that okay?
If it is, then: a camera is something you own, so surely I'm entitled to record anything that's where the camera is?
It also doesn't address things I can e.g. see from my house. Can I put a camera on a tree in a house that happens to have a good view of the neighbour's bathroom or bedroom or whatever?
I don't understand why it's okay to covertly film a gang banger beating the crap out of someone in a "one party system". Neither of the involved parties are aware they're being recorded. If the argument is that the person filming it is involved by virtue of the fact that they're filming it, then why aren't then they allowed to sneak a camera into your neighbour's house to record them? I mean, you're still aware that they're being recorded. I don't see how your lack of physical presence means anything, because in the former case (gang banger) nobody involved was aware of your presence then, either.
Is it not that the one-party system prevents it, but because you need to break other laws (e.g. trespass) in order to do it?
But I still don't see why it's okay to film people without their consent under one-party, but not under two-party, unless you're one of the involved parties.
How can a Flash app be design to allow for search?
By putting most of the content in searchable formats (probably XML), and probably by following some kind of standards. I mean, Flash apps can be made accessible too, but most developers don't bother. Plus, a well-designed site can have a simple version that can easily be indexed (using e.g. the sitemap XML for search engines) and a "rich" version which might be harder to index. So it's a problem that can be solved in multiple ways. At worst, the .swf could be decoded, and any text blobs within it parsed.
But my point was, sites need search engine traffic more than the search engine needs the site. Yes both are dependent on the other, but unless a great big chunk of the web moves en masse, they'd only be hurting themselves (unless they're in some kind of niche where they don't care about search engine traffic). Or in other words, the onus isn't on Google to find a way to index their site, but on the site owners to make sure that whatever they do, they're still in Google. If a big site blocks a search engine from indexing it (whether via Flash or Java or robots.txt) then other sites will be more than happy to take the extra traffic.
Not if the Flash is well-designed, and if it's not well-designed then the site using it will lose ranking in the search engines. I don't think Google really needs to go out of its way to index content nowadays, as if you're not in Google then you don't exist for a lot of the web's users...
You do get the option to disable ads if you have high enough karma. I saw this when my last subscription ran out.
Firstly, the people spending their time breaking the copy protection are the ones already doing that. It's not something you'd have to do yourself.
Secondly, it's pretty interesting that you say you're willing to pay for a product that "just works" without having to faff around. Because that is actually a large incentive for people to pirate games and other software: the pirated version just works. If you buy it then you have to at best keep track of a license key; at worst, you have to activate it online (hoping their activation servers are working at that time), maybe even have to be connected to the internet every time you run it, potentially run out of activations if you change computers a lot or they have a low limit to start with (and then you have to contact their support asking for more activations for something you supposedly "own").
So with this model, you get to periodically buy new content from them. You have to hope they have sufficient bandwidth to deal with the surge of customers also buying the updated content. You have to hope their payment system doesn't have any problems -- not to mention that many of Codemaster's target market probably don't have credit cards or an easy way to make online payments in the first place. Then you have to hope their copy-protection system recognises your right to play the new content, etc.
The pirate on the other hand downloads a complete, working game with all the added content likely built-in; or if they're getting the content later the activation stuff will be removed. So it will in fact "just work". They aren't dependent on some company keeping their authentication servers running, or having enough bandwidth for the initial rush when new content is first released.
Additionally, there are still a lot of people who refuse to buy things online, which I think is going to make things interesting for companies basing their business model on DLC. I see this a lot on various game forums I visit.
True, but neither would his wife.
The story below that recently appeared on Not Always Right seems appropriate:
(A customer is wondering why her anti-virus is asking her to purchase the program.)
Me: "What is the name of your anti-virus?"
Customer: "It is [name of a well-known fake anti-virus program]."
Me: "Ma'am, that is a fake anti-virus. Do not purchase that program because it will not protect your computer."
Customer: "No! Why do you want me to disable my anti-virus? I will not get rid of it! It's keeping my computer safe! I already purchased it three times and it still wants me to pay again! All I want to know is how to stop it from asking me to pay!"
If your "server daemon" enters an infinite loop, then it's definitely a bug. Of course you want it to be shut down cleanly sometimes, which means it has to have some mechanism for ending the loop, cleanly ending any current sessions, and releasing resources.
Which is interesting way of saying that Google is, to some small extent, profiting from providing links to sites that enable copyright-infringement. That is to say, Google would prefer not to remove these sites from their index because if they do, people looking for that stuff will use a different search engine -- thus reducing traffic to Google, which reduces their appeal to advertisers.
And the point I was making was that if they do that, then you don't simply risk having machines unpatched against a known and actively exploited vulnerability for up to a month, but you pretty much guarantee it. Your stance assumes that a vulnerability that has been privately reported is not only likely to be being actively exploited already, but is also likely to be being exploited against a sufficiently large number of machines so as to be a concern for the majority (or even a significant minority) of users.
Whether or not this is true is largely guesswork, but there are lots of security firms who monitor for unusual traffic patterns and any vulnerability that is being widely exploited tends to be picked up. If we trust the methods they use for collecting data on wild exploits, then it currently appears that they neither assumption is true.
As you say, it takes time to test patches, so there is an unavoidable window during which the fix will be published and widely available but not yet deployed to machines, putting them at very high risk (because anyone who wants to can create a tool to exploit the vulnerability). This will occur whether you immediately release the patch or wait. If you know exactly when the patches are coming out (even if you don't know what they're for) then you can plan around testing them at a particular time, thus reducing that window of maximum exposure as much as possible. If patches are issued as soon as they're ready, then the people doing the testing need to drop all their other activities on the floor at a moment's notice in order to get it out ASAP. That's usually not practical, as the people doing the testing have other tasks that they need to perform.
The point is they'll likely set aside a particular day each month or fortnight or week for testing patches. It's much easier to run a test against a bunch of updates all at once than against every individual update. Additionally, it's not only large companies that want to be able to test patches before pushing them out. Most companies don't have the resources to do patch testing at all (or more accurately: the cost/benefit ratio doesn't work out as it's easier to just fight the fire afterwards on the rare occasion a patch does break something) but some companies do need to, and not all have resources to have staff available to test the patches whenever they are released, but instead have scheduled times when they can do that.
So the idea is to minimise the time window between "everyone-and-his-dog being able to exploit the vulnerability" and "patch deployed to all machines". It is guesswork, of course. But basically: if the vulnerability isn't being actively exploited then it's not really a threat, just like the hundreds of other vulnerabilities that exist in your software right now which nobody has discovered. If you publish a patch to fix it for the use of the general public, then absolutely everyone with an interest in exploiting machines can easily determine how to take advantage of the vulnerability in any machine which isn't yet patched. So the time window between releasing the fix and having the patch installed is arguably the point where you're most vulnerable to it.
And it doesn't really matter if a handful of people know about the exploit. The likelihood of any one random blackhat attacking YOUR infrastructure is very small. But the bigger the pool of random blackhats grows, the more significant that very small likelihood becomes.
I mean, the sin has already been committed in that there's a vulnerability that can be exploited. There is no perfect fix for it, just like there's no way to "make it right" after you accidentally kill somebody. All you can do as a vendor is play the statistics and do whatever you can to maximise the % who don't get compromised by the vulnerability. As an end-user, all you can do is try to maximise the likelihood of you being in the % who don't get compromised.
Well they do have a tool to allow corporations to decide when to push patches - WSUS. And any organisation large or savvy enough to be testing patches before deploying them to workstations is going to be using it.
I think the reason for the Patch Tuesday release is to avoid disclosing the vulnerability to all and sundry. Otherwise, if the company doesn't want /to cannot test and deploy patches whenever they get released, there's going to be a period of time during which they have a vulnerability which is not only known, but attackers have the fix for it and can determine exactly what was changed to close it, thus making it very easy to generate an exploit for it.
Microsoft do occasionally release out-of-cycle patches for severe issues that are being actively exploited, so it's not as if they stick rigidly to the cycle even when it's clearly doing more harm than good.
The beer was still sold on a day when it's not permitted to sell it, and thus the law was broken. Just because you can get away with breaking the law doesn't mean the action is legal.
Look at this way: what if a police officer had happened to be in the store at the same time and witnessed it?
Option a) the shopkeeper doesn't attempt to stop the transaction, and gets charged with violating the law prohibiting the sale of alcohol on a Sunday.
Option b) the shopkeeper tells the woman she can't buy that, and she walks out with the beer regardless. She gets charged with theft.
There is also the possibility of option c) the police officer doesn't bother to enforce a law he sees as pointless. In which case, he potentially gets charged with whatever it is police officers are charged with when they fail to uphold the law.
Well the corporate filesystem itself has shadow copy so if we need to restore anything from the last 2 weeks or so it's right there in the 'previous versions' context menu. Users can even do it themselves - can't beat that for convenience. There's around 3 TB of local storage on the backup server which goes over to databases, email, system state, virtual machine images, and probably some other things I've forgotten.
The filesystem is about 1.5 TB and that goes right to tape. No sense using the local storage for backing that up when it's already checkpointed several times a day.