Link to Original Source
if Facebook wants to do business in Germany, then it must abide by German laws.
Does "do business" mean sell advertising or does it mean allowing citizens of Germany to access it's pages. I can see how Germany could legally control allowing foreign companies from doing business in Germany (selling advertising in this case), but I don't see how Germany could prevent its citizens from accessing the whole internet (Facebook in this case), unless it wants to try to be like China or North Korea. I can see trying to restrict the monetary flow in or out of a country, but trying to restrict the information flow seems both wrong and futile.
The child, identified only as "G" in court documents
Well there is the problem. If the child identified himself as "N", there wouldn't be a conflict and the kid would learn faster.
My suspicion there is a feature which gets the machine hibernated while sleeping, to recover in the case of a power outage. The feature pretty much kills the usefulness of sleep, though, if every wake is a wake from hibernate.
Assuming your machine is configured properly: When you sleep, as you suspected, memory is written out to disk as insurance against power is lost. When you come out of sleep (assuming you didn't lose power), Windows resumes from sleep without reading everything back in from disk. If you did lose power, Windows resumes from hibernate and reads memory back in from disk.
You are getting a salary like any other job, and you have the chance of becoming rich on top of that, without any more investment. Doesn't seem like a lie to me.
As long as you don't consider the the value of your stock options as part of your compensation, I would agree. If you are making as much in salary and other benefits that have current value (health care, retirement plans, working conditions, etc.) than you would at another job without options, then it is not a lie. If, on the other hand, you are forgoing some salary in exchange for a future possible value (stock options), then it is likely a lie (or at least a gamble with low odds).
They just need to be enough to make it through standard operating conditions, not outright attacks.
As soon as you connect something to the Internet, "standard operating conditions" include outright attacks.
You ask why users break policies. I guess there can be many reasons but for me anytime a policy gets in the way of accomplishing a task, it gets broken.
Another way of saying this is polices are likely to be broken when policies conflict. While not using your smart phone may be a policy, getting your job done is also a policy. In this case people will generally choose to break the policy with the least personal risk. If I am more likely to be fired (or not paid my bonus) if I don't get my job done than if I use my cell phone, I am going to choose getting my job done and use the phone anyway.
If am using my phone against policy, I may also do things that are detrimental to the business while I am trying to hide my phone usage. At a minimum I am wasting time and brain cycles thinking about how to deal with the policy conflict.
There was this movie that among other things was about unintended consequences that can happen if you have conflicting policies / instructions. "Open the pod bay doors, HAL".
Do you think gmail would have become the most popular email service if it would have used ACID? ACID is *not* the only option. It's the *old* option. It's the expensive and slow option.
Maybe ACID doesn't mean what you think it means. It is not a technology that is "old" or "new", it is a way to think about the requirements of your system. Each of the four letters in ACID stands for a particular property of a database system and these properties (in various combinations) may or may not be needed by the system being built.
If your system is processing something where the integrity of the data is important (like financial systems), you are very likely going to need all four properties. If you are moving money from one place to another, you want to guarantee that that the the money is completely moved or not. You don't want the money partially moved, you don't want money to be lost, and you don't want money to be created out of thin air. ACID (as a concept) guarantees this.
If your solution requires ACID, you don't have to use a database that supports all of the properties of ACID, you could instead implement ACID in your application layer. However if you do this, you have to guarantee that that your application layer implements it properly and that there is no possible way to get to the underlying data store without going through the application layer. You also have to guarantee that no changes, updates, upgrades, or bugs in your application layer every break the ACID guarantee at any time. Making all of these guarantees in your application layer is VERY HARD, which is why people use ACID complaint databases instead to solve this particular problem set.
If your requirements don't need the properties described by ACID, than there isn't anything wrong with using a non ACID database. If may be acceptable for your data to "eventually" become consistent, to be inconsistent, or maybe even lost.
In the gmail example, you don't really need all the ACID properties, so you don't need to use that sort of database to hold the information. Email is not transactional end to end; when you send an email you are not guaranteed that it will get there. Email is also not order guaranteed; if you send multiple emails there is not a guarantee (or need) for them to arrive in the destination mailbox in order. If you are bulk moving messages from one mailbox to another, and only some of them get moved, it is okay and you can just move the remaining messages later.
As always, it is important to chose the right technology to solve the problem you need to solve. ACID compliant databases solve a lot of important problems (usually involving money), and if you have one of those problems, there is nothing "old" about ACID.
Anything cut to length will be too short.