You can never pay someone enough that they can't be paid some more to "lose" a laptop with data on it.
We work hard to mitigate corporate espionage (which is surprisingly common), but no matter how much they're paid, someone can get greedy and take a $30k bonus in cash to give up some data.
Session state is maintained on the server, not the client.
Overall state is a combination of the session on the server and the values on the client (such as in forms).
You're right, the web is not the most ideal from a user interface perspective for delivering applications. However it's substantially the simplest delivery mechanism both from the user's perspective and from the developer's perspective.
It's certainly possible to account for every possible combination of back-and-forward button clicks, but this is very expensive in terms of developer time when you're considering complex web applications. Sometimes it legitimately doesn't make sense to hit Back. I wouldn't say that disabling back all together makes sense, but I do think that it makes sense to say, "If the user pushes Back, take them to this page in their history."
For example a custom HTTP header named "Page-ID: OrderStep1" (settable of course also in tags), with a "Back-Goes-To: OrderStep1" header on steps 2, 3, and 4. If you have a "Back-Goes-To" with an ID the user has not been to yet, then it works like a normal back button. Alternatively, "Disable-BackButton-To-This-Page: Yes"
This way you can't lock a user into your site and you cannot really inconvenience them so much as require that they follow a set of steps in a given order.
Wish I still had the mod points I had yesterday, I'd undo your flamebait moderation as it's unfair.
Try <script>window.history.forward();</script>
There is a difference between a web application and a web site. Normal applications rarely have a back button (except when going through a wizard), it does not always make sense for a web application to have a back button.
One of your responders points out that state is managed on the server and not the client. I'll point out that state is a combination of what's on the client and what's on the server.
We get many customer complaints for our web apps that are the consequence of a customer hitting back. Not because our app barfs when you hit back, but because the behavior is relatively undefined and becomes confusing for the customer (each customer expects it to behave in the way most beneficial to their intention, and this is not consistent between customers).
Let me give an example. Some of our customers are buyer accounts; usually a corporate office with many branch offices. They can buy for many ship-to customers. Each ship-to customer has its own set of possible contracts, product availability, shipping timeline, etc. Basically depending on what ship-to you're selected on, the rules are different.
Because the rules are different for each ship-to, when you change your ship-to, your cart is emptied (some of those items might not be available to your new ship-to, especially if that new ship-to doesn't have the legal license required to buy some of these products). Rather than remove only the unavailable items, cap the items that have new purchasing limits, etc, our research has found it's simply less confusing for the customer to empty their cart for them and make them start the ordering process again. The customer is warned that they'll lose their current cart contents before changing their ship-to.
Well some customers unfortunately need to place an identical order for a dozen or more separate ship-to's. The most intuitive way to do this of course is: 1) Select first ship-to, 2) place order, 3) change ship-to, 4) click back to the pre-submit confirmation screen, 5) re-submit the previous order on the new customer.
Well, so what do we do? Do we place the order if possible (the new ship-to meets all eligibility requirements), or do we rely on the fact that having changed the ship-to has emptied the cart, so all the quantities coming into that order are meaningless? To us we have to rely on the fact that the cart got emptied invalidates the information on the final step; the new ship-to might not be allowed to order all these products, might have a different contract, might have multiple contracts (and has not chosen which contract they want to apply), etc.
When you have things which have to be done in a certain order because each step of a process depends on the answers to the previous step, then it does not make sense to go 1a->2a->3a->4a->1b->3a->4b (where the b's are the second actual loading of those pages). It is safe to say this behavior is undefined. We define it to be the very safe, "start over" clause.
This is not even a complex scenario, we have apps (especially internal) that are substantially more complex than this. We give you a "Back to previous step" button, this maintains logical flow correctly; when you start jumping around in the steps and we have no control over that, it's substantially harder to define the outcome of every possible permutation of what order the customer feels like going through the steps.
This is a nice aspect of Ajax apps actually; we can take you through a multi-step process without you being able to use your browser's Back button to jump around in the steps except that you leave the process entirely and start it over again.
You both underestimate the importance of nomenclature. Instead of worrying about genus and species, scientists should just focus on studying animals!
For one thing, they've been doing this for a lot of years, they can work on whatever aspects they think are important and I'll trust them to know what they're doing.
For another, version numbering is significant. It gives developers something to latch on to. "Fixed in 2.6.20-18" This is much better than "Fixed in May." Adopting numbering schemes allows system administrators and developers to infer certain information about a kernel version without having to go look up details on that version. EG, 2.4 kernel = stable, 2.5 kernel = unstable, etc.
This is a very important issue, it streamlines communications and work all throughout the kernel lifecycle.
Plus Firebug 1.2 already does what their patch does. If you want to see what the final execution result is, click the dropdown in the Scripts window to see the text of all eval() calls.
How long until they do setTimeout("final code", 1) instead of eval(), and how long until they do document.write("<div id='foo' onclick='malware.code;'></div>"); document.getElementById('foo').onclick(); etc? As gp said, it's a malware arms race, they're changing their obfuscation techniques to bypass the current market tools.
There's a lot of ways to generate on-the-fly code to execute in javascript, automated tools are going to have a hard time coping with all possible variants.
If the Amazonian gets food and water and safety in the city, why doesn't the city guy get those in the Amazon?
How about this? Don't give either one anything. I suspect success would be pretty similar for both.
Some city guys would eat something poisonous, drink some impure water without boiling it (and die of dehydration from dysentery), or die of exposure. But also, some city guys would figure out how to rig themselves a shelter, observe where the animals are drinking and remember that he probably should boil that, figure out how to start a fire, and identify some fruits that the monkeys are eating.
I think it would be hard for an amazonian to survive the winter in the city without the benevolent provider and protector you provide them. I think it would be even harder for an amazonian to avoid being arrested let alone shot. He'd walk around without sufficient clothing, he'd point a self-made spear in someone's face, he'd steal food from a convenience store, and when it started getting cold, he'd start a fire.
If he's especially lucky he gets your benevolent protectorship in the form of a state funded room in a mental hospital. If he's not lucky he wouldn't know where to get winter clothes, or he'd get shot by a wacko or store clerk.
I feel like I've stepped into a Twilight Zone thread, where you say one thing, and people respond as if you said something completely different.
The original point (now GGGGGGGP or something) was that it's not uncommon for a game's demo to be heavily tested and bug fixed so that it is not representative of the quality and stability of the retail version of the game. You try the demo, exercise as much due diligence as you are able to with it, and you are satisfied with the game's quality. But then when you load up the retail version of the game, you're not able to play it, or the content that wasn't in the demo is buggy and unstable.
This is not that uncommon, it happens for several reasons: 1) The demo content is tested substantially more aggressively than the rest of the content for release, because the demo directly affects sales while the rest of it only indirectly. 2) The demo lacks copy protection, while the retail version has it tightly packed in. Copy protection is the number one thing which is likely to interfere with my ability to play a game, and you can't test that in the demo.
So the original point was: maybe the demo is great and the retail version sucks. Nobody is claiming that the demo sucked and you bought the retail version anyway, they're only saying that just because the demo doesn't suck doesn't mean the retail version doesn't either.
Without preshared keys, this is vulnerable to a man in the middle attack. Your ISP or the government's spies or whoever simply intercept your communications with the other peer at the time of hand shaking and key exchange, and hands their own encryption information to both parties. Decrypt each message, and encrypt it for the other party before sending it down the line.
This protects against casual snooping, but it completely fails to account for the level of involvement that domestic spying already suffers from.
For convenience sake, I'll call the "fire, libel, loss, accident, damage, or injury" phrase simply "damage," and "to a person or to property" a "something." Likewise, "engaging in the business of obtaining or furnishing [etc]... information related to" I'll call investigate.
The section you cite talks about investigation into the damage of something.
Some kind of loss or damage has occurred, if it's your business to investigate how in a context of providing legally supportable information in this regard, they're saying you need a PI license. If you want to take this to court, you basically have to have first proven you're familiar with the laws in your state on such matters, and you have to put your license on the line for revocation should you be found to be negligent (willfully or otherwise) in your investigation.
If interpreted the way you interpreted this (which I don't think it can be without distortion), then you wouldn't even be able to look at a source control Blame report for who created a bug: it's a work computer so you qualify for "accepts employment," and the bug ostensibly qualifies as a loss (especially certain types of bug); finding out who did it or exactly how the bug is wrong would be "cause or responsibility."
In your interpretation: Boss: Who failed to check their buffer length? Programmer: Hmm... [svn blame]... Looks like Joe. Undercover cop: You're under arrest!
You crudely assume that every slashdotter is located in the USA.
I don't mean to troll here, but I'm really tired of hearing this complaint all the time. When an article comes up about Canada, I don't get on and complain that Canadians are writing comments targeted toward other Canadians. When an article comes up about politics in England, and someone posts a comment that talks about writing your MP's or whatever they are in England, I don't complain about that either.
If the comment doesn't apply to you, then it was probably not addressed to you, and complaining about it otherwise is worthless noise. Not every comment on the Internet is necessarily meant as a personal note to you, even if the submitter wasn't extra super careful to make sure that the text reads that way.
Don't read comments about politics on foreign countries then get upset when the comments on that article are primarily centric to that country! Sheesh.
Honestly, Green is pretty in right now, places like this might find they boost their tourism since tourists will feel good about themselves for visiting an ecologically friendly place like that.
These windmills are fairly elegant looking I think. They're not eyesores at all, and whenever I pass one along the highway, I'm happy to see it.
Man, this is so sadly true. I worked for a company for about 6 months before leaving for greener pastures. They sent mass marketing emails multiple times per month, with as many as 10,000 recipients. They were cautious to not send messages to any one recipient too often so they didn't piss off that person.
The fact is that given the quality of their messages - they weren't V1gara Ci1ais, they weren't scam attempts, and in fact they were pretty carefully targeted based on what industry vertical you were in - they actually had a pretty high response rate. For most campaigns they saw 10-15% response, and they had sales reps personally contact each of those responders (now known as leads).
The calculated lead-to-sale value for email campaigns based a floating 6-month average was around $1,600 (the software cost anywhere from $10,000 to $150,000 depending on which modules you purchased with it, and including 1 year of support maintenance - many customers actually signed on for many years, but it's not considered part of the initial sale). I don't know what the percentage was for lead-to-sale, they didn't track it that way.
So for every person who filled out a contact form from following the link in an email, they made an average of $1,600. When you're sending 10,000 emails for a single campaign, and you have a 10% response rate, each of which is worth $1,600, that campaign profited $16,000. It's hard to argue against this.
In addition, many of those contacts turn into sales later and aren't tracked as a email-to-sale because the email only enabled the relationship with the sales rep to open up, and the sales rep was able to make an independent sale months or possibly years later which wouldn't have been possible without the email sparking an interest.
The company wasn't interested in the moral implications. They weren't interested in the legality of it so long as they adhered to the bare minimum that was required to be legal. They were interested in this thing which provided 100-fold plus return on investment so long as they didn't try to wring to much out of it or otherwise abuse it.
Of course they had to honor opt-out requests, and they did. But they received fewer opt-outs for each campaign than they received leads; and often times the leads they received weren't from the person who received the email, but were actually a colleague who forwarded the message to their coworker or friend; they might actually have added more new recipients each campaign than opted out.
Man, non-recycled aluminum has a HUGE environmental footprint. It requires massive strip mining of bauxite ore, and a tremendous amount of energy to refine.
Aluminum metal reacts very easily with Oxygen to form aluminum oxide (Al2O3, "alumina"), this is a solid compound. The reason aluminum doesn't corrode in the atmosphere is that it forms a layer of aluminum oxide very quickly which protects the rest of the metal from exposure to oxygen.
If this reaction is actually oxidation of aluminum oxide, then it's wrong to call water the fuel. Doing so is like claiming gasoline-powered cars run on oxygen.
It's also only using the pure aluminum as a way to store the massive electrical currents used to purify aluminum at the factory. If this car went into mass production, it would be really bad for the environment. Aluminum requires too much energy to produce and refine, and hurts the environment to be used as a disposable resource. We'll also run out of bauxite long before we run out of fossil fuels.
It's also not even carbon neutral unless the trucks which haul bauxite or other aluminum oxide for refinement run on this same technology, and the power plants providing electricity to the aluminum refinery are nuclear only. It simply shifts the origin of the carbon, and does nothing else.
It's cute, but it's not actually accurate. Appeal to authority only applies if an arguer uses their own authority as the argument. From your own link it is, "a type of argument in logic consisting on basing the truth value of an assertion on the authority, knowledge, expertise, or position of the person asserting it," (emphasis mine).
It would be an A2A if a Wikipedia article claimed it doesn't need citations because of it being a Wikipedia article, or only cited other Wikipedia articles which themselves had no citations or only cited yet other Wikipedia articles.
The issue is that for gasoline, its pre-combustion form represents a higher energy state than its post-combustion form (generally CO2 and H2O, maybe some CO if it's not running efficiently and of course other impurities in the gas). When you split up the molecule it releases energy. It requires a small amount of energy to start the split, and returns a much larger amount of energy, some of which is used for propulsion, and some of which is used to ignite the next engine cycle.
With water, H20 represents the lower energy state. It devolves into H2 and O2, but getting there requires exactly as much energy as getting back to H2O (burning H2 in an O2 environment yields H2O). Thermodynamics states that every time we convert energy states, some of it is "lost" to entropy (it's not possible to reclaim all gained energy, and it's not possible to not lose some of the energy being supplied into the equation). But even if it you had an ideal (no loss of energy) water separation and combustion system, going from 2xH2O -> 2xH2 + O2 -> 2xH2O again would yield no bonus energy that you could use for other purposes. It requires N joules of energy to go from 2xH2O to 2xH2 + O2, and you receive N joules of energy to go from 2xH2 + O2 -> 2xH2O, no energy is created.
You can't create energy from nowhere with any known modern physics. You can only harvest energy that is available in other forms, and convert it to the form you find convenient. Gasoline's energy (all fossil fuel based energy) is actually solar energy stored there thousands or millions of years ago by plants who have decayed but left behind energy-rich deposits. Photosynthesis was responsible for using the solar energy to create molecules in a high energy form, and many years later we convert those molecules back into their low energy form and capture the energy released as a result.
They're typical UI's created by developers: they're meant to be compact, efficient, and without frill. Incredibly efficient to use if you have already habituated to the UI, but a nightmare to learn if you're getting your feet wet.
In the US, the SIM is often soldered directly as part of the main board, or else affixed with a thick coat of opaque black epoxy.
They are designed to be either impossible to remove without destroying the phone, or else so incredibly difficult and risky to the phone anyway that they might as well be. It's a design consideration in the phone, and they take extra steps to ensure that you can't transfer the device to a different carrier for no purpose other than to force you to buy a new one when you switch.
Nokia doesn't care whether you use their phone, they only care whether you buy it. SIM locks mean you have to buy a new phone each time you switch carriers, thus giving them another shot at your wallet.
Make no mistake, phone manufacturers benefit from SIM locks just like carriers do. After all, they're the one selling you the new phone each time you switch carriers.
DRM is 100% Security Through Obscurity. They give you everything you need to produce an unencrypted version of something, and hope to high heaven that the only time it ever exists in unencrypted form is some place you don't think to look for it.
An open source DRM module couldn't possibly work. Well, it could, but it would be very easily crackable - instead of sending the unencrypted stream to the screen and speakers, send it instead to ff4mpeg or to a disk and have it re-encoded.
Every major DRM scheme has been broken to date, and that's without having the source code available. Having the source means you just redirect the output to some place you can capture it, and you're done.
but we are not yet ready to play by the rules; but this needs to work the other way round too
So you're not yet ready to play by our rules, but you want us to play by your rules so that you have an opportunity to take advantage of the work we produce and provide to you for free (beer/speech); when the only stipulation we have is that you provide it back for free?
I'm sorry, it sounds like you have your head firmly rooted somewhere dark and unnatural.
"These things suck and hurt both you and us, and we won't bend on that. But we want you to work for us for free anyway."
Holy cow man, listen to yourself. This is our playground and we give you an opportunity to play in it for free; in return we purchase the goods you produce as a result. You play by our rules or we take our playground and our purchasing power to someone who will.
Slashdot Mirror
You can never pay someone enough that they can't be paid some more to "lose" a laptop with data on it.
We work hard to mitigate corporate espionage (which is surprisingly common), but no matter how much they're paid, someone can get greedy and take a $30k bonus in cash to give up some data.
Overall state is a combination of the session on the server and the values on the client (such as in forms).
You're right, the web is not the most ideal from a user interface perspective for delivering applications. However it's substantially the simplest delivery mechanism both from the user's perspective and from the developer's perspective.
It's certainly possible to account for every possible combination of back-and-forward button clicks, but this is very expensive in terms of developer time when you're considering complex web applications. Sometimes it legitimately doesn't make sense to hit Back. I wouldn't say that disabling back all together makes sense, but I do think that it makes sense to say, "If the user pushes Back, take them to this page in their history."
For example a custom HTTP header named "Page-ID: OrderStep1" (settable of course also in tags), with a "Back-Goes-To: OrderStep1" header on steps 2, 3, and 4. If you have a "Back-Goes-To" with an ID the user has not been to yet, then it works like a normal back button. Alternatively, "Disable-BackButton-To-This-Page: Yes"
This way you can't lock a user into your site and you cannot really inconvenience them so much as require that they follow a set of steps in a given order.
Wish I still had the mod points I had yesterday, I'd undo your flamebait moderation as it's unfair.
Try <script>window.history.forward();</script>
There is a difference between a web application and a web site. Normal applications rarely have a back button (except when going through a wizard), it does not always make sense for a web application to have a back button.
One of your responders points out that state is managed on the server and not the client. I'll point out that state is a combination of what's on the client and what's on the server.
We get many customer complaints for our web apps that are the consequence of a customer hitting back. Not because our app barfs when you hit back, but because the behavior is relatively undefined and becomes confusing for the customer (each customer expects it to behave in the way most beneficial to their intention, and this is not consistent between customers).
Let me give an example. Some of our customers are buyer accounts; usually a corporate office with many branch offices. They can buy for many ship-to customers. Each ship-to customer has its own set of possible contracts, product availability, shipping timeline, etc. Basically depending on what ship-to you're selected on, the rules are different.
Because the rules are different for each ship-to, when you change your ship-to, your cart is emptied (some of those items might not be available to your new ship-to, especially if that new ship-to doesn't have the legal license required to buy some of these products). Rather than remove only the unavailable items, cap the items that have new purchasing limits, etc, our research has found it's simply less confusing for the customer to empty their cart for them and make them start the ordering process again. The customer is warned that they'll lose their current cart contents before changing their ship-to.
Well some customers unfortunately need to place an identical order for a dozen or more separate ship-to's. The most intuitive way to do this of course is: 1) Select first ship-to, 2) place order, 3) change ship-to, 4) click back to the pre-submit confirmation screen, 5) re-submit the previous order on the new customer.
Well, so what do we do? Do we place the order if possible (the new ship-to meets all eligibility requirements), or do we rely on the fact that having changed the ship-to has emptied the cart, so all the quantities coming into that order are meaningless? To us we have to rely on the fact that the cart got emptied invalidates the information on the final step; the new ship-to might not be allowed to order all these products, might have a different contract, might have multiple contracts (and has not chosen which contract they want to apply), etc.
When you have things which have to be done in a certain order because each step of a process depends on the answers to the previous step, then it does not make sense to go 1a->2a->3a->4a->1b->3a->4b (where the b's are the second actual loading of those pages). It is safe to say this behavior is undefined. We define it to be the very safe, "start over" clause.
This is not even a complex scenario, we have apps (especially internal) that are substantially more complex than this. We give you a "Back to previous step" button, this maintains logical flow correctly; when you start jumping around in the steps and we have no control over that, it's substantially harder to define the outcome of every possible permutation of what order the customer feels like going through the steps.
This is a nice aspect of Ajax apps actually; we can take you through a multi-step process without you being able to use your browser's Back button to jump around in the steps except that you leave the process entirely and start it over again.
You both underestimate the importance of nomenclature. Instead of worrying about genus and species, scientists should just focus on studying animals!
For one thing, they've been doing this for a lot of years, they can work on whatever aspects they think are important and I'll trust them to know what they're doing.
For another, version numbering is significant. It gives developers something to latch on to. "Fixed in 2.6.20-18" This is much better than "Fixed in May." Adopting numbering schemes allows system administrators and developers to infer certain information about a kernel version without having to go look up details on that version. EG, 2.4 kernel = stable, 2.5 kernel = unstable, etc.
This is a very important issue, it streamlines communications and work all throughout the kernel lifecycle.
Plus Firebug 1.2 already does what their patch does. If you want to see what the final execution result is, click the dropdown in the Scripts window to see the text of all eval() calls.
How long until they do setTimeout("final code", 1) instead of eval(), and how long until they do document.write("<div id='foo' onclick='malware.code;'></div>"); document.getElementById('foo').onclick(); etc? As gp said, it's a malware arms race, they're changing their obfuscation techniques to bypass the current market tools.
There's a lot of ways to generate on-the-fly code to execute in javascript, automated tools are going to have a hard time coping with all possible variants.
If the Amazonian gets food and water and safety in the city, why doesn't the city guy get those in the Amazon?
How about this? Don't give either one anything. I suspect success would be pretty similar for both.
Some city guys would eat something poisonous, drink some impure water without boiling it (and die of dehydration from dysentery), or die of exposure. But also, some city guys would figure out how to rig themselves a shelter, observe where the animals are drinking and remember that he probably should boil that, figure out how to start a fire, and identify some fruits that the monkeys are eating.
I think it would be hard for an amazonian to survive the winter in the city without the benevolent provider and protector you provide them. I think it would be even harder for an amazonian to avoid being arrested let alone shot. He'd walk around without sufficient clothing, he'd point a self-made spear in someone's face, he'd steal food from a convenience store, and when it started getting cold, he'd start a fire.
If he's especially lucky he gets your benevolent protectorship in the form of a state funded room in a mental hospital. If he's not lucky he wouldn't know where to get winter clothes, or he'd get shot by a wacko or store clerk.
If you can't trust your ISP not to act as a MITM agent, then you can't trust them to give you a valid DNS TXT record either.
I feel like I've stepped into a Twilight Zone thread, where you say one thing, and people respond as if you said something completely different.
The original point (now GGGGGGGP or something) was that it's not uncommon for a game's demo to be heavily tested and bug fixed so that it is not representative of the quality and stability of the retail version of the game. You try the demo, exercise as much due diligence as you are able to with it, and you are satisfied with the game's quality. But then when you load up the retail version of the game, you're not able to play it, or the content that wasn't in the demo is buggy and unstable.
This is not that uncommon, it happens for several reasons:
1) The demo content is tested substantially more aggressively than the rest of the content for release, because the demo directly affects sales while the rest of it only indirectly.
2) The demo lacks copy protection, while the retail version has it tightly packed in. Copy protection is the number one thing which is likely to interfere with my ability to play a game, and you can't test that in the demo.
So the original point was: maybe the demo is great and the retail version sucks. Nobody is claiming that the demo sucked and you bought the retail version anyway, they're only saying that just because the demo doesn't suck doesn't mean the retail version doesn't either.
Without preshared keys, this is vulnerable to a man in the middle attack. Your ISP or the government's spies or whoever simply intercept your communications with the other peer at the time of hand shaking and key exchange, and hands their own encryption information to both parties. Decrypt each message, and encrypt it for the other party before sending it down the line.
This protects against casual snooping, but it completely fails to account for the level of involvement that domestic spying already suffers from.
For convenience sake, I'll call the "fire, libel, loss, accident, damage, or injury" phrase simply "damage," and "to a person or to property" a "something." Likewise, "engaging in the business of obtaining or furnishing [etc]... information related to" I'll call investigate.
The section you cite talks about investigation into the damage of something.
Some kind of loss or damage has occurred, if it's your business to investigate how in a context of providing legally supportable information in this regard, they're saying you need a PI license. If you want to take this to court, you basically have to have first proven you're familiar with the laws in your state on such matters, and you have to put your license on the line for revocation should you be found to be negligent (willfully or otherwise) in your investigation.
If interpreted the way you interpreted this (which I don't think it can be without distortion), then you wouldn't even be able to look at a source control Blame report for who created a bug: it's a work computer so you qualify for "accepts employment," and the bug ostensibly qualifies as a loss (especially certain types of bug); finding out who did it or exactly how the bug is wrong would be "cause or responsibility."
In your interpretation:
Boss: Who failed to check their buffer length?
Programmer: Hmm... [svn blame]... Looks like Joe.
Undercover cop: You're under arrest!
The article sections you quote don't provide for the hypothetical you propose.
Worked for me from Ubuntu.
If the comment doesn't apply to you, then it was probably not addressed to you, and complaining about it otherwise is worthless noise. Not every comment on the Internet is necessarily meant as a personal note to you, even if the submitter wasn't extra super careful to make sure that the text reads that way.
Don't read comments about politics on foreign countries then get upset when the comments on that article are primarily centric to that country! Sheesh.
Honestly, Green is pretty in right now, places like this might find they boost their tourism since tourists will feel good about themselves for visiting an ecologically friendly place like that.
These windmills are fairly elegant looking I think. They're not eyesores at all, and whenever I pass one along the highway, I'm happy to see it.
Probably just a typo, but 0 xor 0 = 0
Man, this is so sadly true. I worked for a company for about 6 months before leaving for greener pastures. They sent mass marketing emails multiple times per month, with as many as 10,000 recipients. They were cautious to not send messages to any one recipient too often so they didn't piss off that person.
The fact is that given the quality of their messages - they weren't V1gara Ci1ais, they weren't scam attempts, and in fact they were pretty carefully targeted based on what industry vertical you were in - they actually had a pretty high response rate. For most campaigns they saw 10-15% response, and they had sales reps personally contact each of those responders (now known as leads).
The calculated lead-to-sale value for email campaigns based a floating 6-month average was around $1,600 (the software cost anywhere from $10,000 to $150,000 depending on which modules you purchased with it, and including 1 year of support maintenance - many customers actually signed on for many years, but it's not considered part of the initial sale). I don't know what the percentage was for lead-to-sale, they didn't track it that way.
So for every person who filled out a contact form from following the link in an email, they made an average of $1,600. When you're sending 10,000 emails for a single campaign, and you have a 10% response rate, each of which is worth $1,600, that campaign profited $16,000. It's hard to argue against this.
In addition, many of those contacts turn into sales later and aren't tracked as a email-to-sale because the email only enabled the relationship with the sales rep to open up, and the sales rep was able to make an independent sale months or possibly years later which wouldn't have been possible without the email sparking an interest.
The company wasn't interested in the moral implications. They weren't interested in the legality of it so long as they adhered to the bare minimum that was required to be legal. They were interested in this thing which provided 100-fold plus return on investment so long as they didn't try to wring to much out of it or otherwise abuse it.
Of course they had to honor opt-out requests, and they did. But they received fewer opt-outs for each campaign than they received leads; and often times the leads they received weren't from the person who received the email, but were actually a colleague who forwarded the message to their coworker or friend; they might actually have added more new recipients each campaign than opted out.
Man, non-recycled aluminum has a HUGE environmental footprint. It requires massive strip mining of bauxite ore, and a tremendous amount of energy to refine.
Aluminum metal reacts very easily with Oxygen to form aluminum oxide (Al2O3, "alumina"), this is a solid compound. The reason aluminum doesn't corrode in the atmosphere is that it forms a layer of aluminum oxide very quickly which protects the rest of the metal from exposure to oxygen.
If this reaction is actually oxidation of aluminum oxide, then it's wrong to call water the fuel. Doing so is like claiming gasoline-powered cars run on oxygen.
It's also only using the pure aluminum as a way to store the massive electrical currents used to purify aluminum at the factory. If this car went into mass production, it would be really bad for the environment. Aluminum requires too much energy to produce and refine, and hurts the environment to be used as a disposable resource. We'll also run out of bauxite long before we run out of fossil fuels.
It's also not even carbon neutral unless the trucks which haul bauxite or other aluminum oxide for refinement run on this same technology, and the power plants providing electricity to the aluminum refinery are nuclear only. It simply shifts the origin of the carbon, and does nothing else.
It's cute, but it's not actually accurate. Appeal to authority only applies if an arguer uses their own authority as the argument. From your own link it is, "a type of argument in logic consisting on basing the truth value of an assertion on the authority, knowledge, expertise, or position of the person asserting it," (emphasis mine).
It would be an A2A if a Wikipedia article claimed it doesn't need citations because of it being a Wikipedia article, or only cited other Wikipedia articles which themselves had no citations or only cited yet other Wikipedia articles.
The issue is that for gasoline, its pre-combustion form represents a higher energy state than its post-combustion form (generally CO2 and H2O, maybe some CO if it's not running efficiently and of course other impurities in the gas). When you split up the molecule it releases energy. It requires a small amount of energy to start the split, and returns a much larger amount of energy, some of which is used for propulsion, and some of which is used to ignite the next engine cycle.
With water, H20 represents the lower energy state. It devolves into H2 and O2, but getting there requires exactly as much energy as getting back to H2O (burning H2 in an O2 environment yields H2O). Thermodynamics states that every time we convert energy states, some of it is "lost" to entropy (it's not possible to reclaim all gained energy, and it's not possible to not lose some of the energy being supplied into the equation). But even if it you had an ideal (no loss of energy) water separation and combustion system, going from 2xH2O -> 2xH2 + O2 -> 2xH2O again would yield no bonus energy that you could use for other purposes. It requires N joules of energy to go from 2xH2O to 2xH2 + O2, and you receive N joules of energy to go from 2xH2 + O2 -> 2xH2O, no energy is created.
You can't create energy from nowhere with any known modern physics. You can only harvest energy that is available in other forms, and convert it to the form you find convenient. Gasoline's energy (all fossil fuel based energy) is actually solar energy stored there thousands or millions of years ago by plants who have decayed but left behind energy-rich deposits. Photosynthesis was responsible for using the solar energy to create molecules in a high energy form, and many years later we convert those molecules back into their low energy form and capture the energy released as a result.
They're typical UI's created by developers: they're meant to be compact, efficient, and without frill. Incredibly efficient to use if you have already habituated to the UI, but a nightmare to learn if you're getting your feet wet.
In the US, the SIM is often soldered directly as part of the main board, or else affixed with a thick coat of opaque black epoxy.
They are designed to be either impossible to remove without destroying the phone, or else so incredibly difficult and risky to the phone anyway that they might as well be. It's a design consideration in the phone, and they take extra steps to ensure that you can't transfer the device to a different carrier for no purpose other than to force you to buy a new one when you switch.
Nokia doesn't care whether you use their phone, they only care whether you buy it. SIM locks mean you have to buy a new phone each time you switch carriers, thus giving them another shot at your wallet.
Make no mistake, phone manufacturers benefit from SIM locks just like carriers do. After all, they're the one selling you the new phone each time you switch carriers.
DRM is 100% Security Through Obscurity. They give you everything you need to produce an unencrypted version of something, and hope to high heaven that the only time it ever exists in unencrypted form is some place you don't think to look for it.
An open source DRM module couldn't possibly work. Well, it could, but it would be very easily crackable - instead of sending the unencrypted stream to the screen and speakers, send it instead to ff4mpeg or to a disk and have it re-encoded.
Every major DRM scheme has been broken to date, and that's without having the source code available. Having the source means you just redirect the output to some place you can capture it, and you're done.
I'm sorry, it sounds like you have your head firmly rooted somewhere dark and unnatural.
"These things suck and hurt both you and us, and we won't bend on that. But we want you to work for us for free anyway."
Holy cow man, listen to yourself. This is our playground and we give you an opportunity to play in it for free; in return we purchase the goods you produce as a result. You play by our rules or we take our playground and our purchasing power to someone who will.