It's tremendously awkward to tell someone that you should buy two copies of the expansion just to get a second 90.
A bit of searching shows that in the past WoW expansions were introduced at $40, so why wouldn't a player opt to buy the expansion twice rather than buying the level upgrade for a second character?
Note that the pricing for this expansion hasn't been published yet, but I doubt they're going to price it at $60, since people expect a full game for that price.
Indeed there is no such thing as secure self-destructing messages. What is more interesting is end-to-end encryption, where you can at least ensure that no-one except the recipient can open the message.
And when the largest Dutch telco announced plans to charge extra for the "privilege" of being able to use IM or VOIP on a mobile data plan, net neutrality legislation was passed in record time.
Right now the arctic ocean and Hudson Bay are 100% frozen due to this thing we call winter. Summer it is a different story.
The summer story is much more relevant though. In winter, when there is a low angle sun a few hours a day, sunlight is reflected back into space. In summer, when the sun is at a higher angle and there are only a few hours of night a day, increasingly large areas are not reflecting much sunlight back into space. I don't see how this invalidates TFA.
But don't forget that big pharma, for all its problems still is the number one creator of new drugs. In 2012 alone, the U.S. government and private companies spent a combined $130 billion (PDF) on medical research.
Ahh, very large numbers without context.
There is a little context:
Last year Novartis lost a six-year legal battle after the Indian Supreme court ruled that small changes and improvements to the drug Glivec did not amount to innovation deserving of a patent.
So some of that research is being spent on patentable variations rather than better cures, which is a waste of time and money when looking at the complete healthcare system. Commercial research also produces actually useful drugs, but perhaps it would be more efficient to let governments lead the research and let pharma companies handle the production side.
If NBC buys television rights for billions of dollars, of course they're going to use those to make money in any way they can. In my opinion the IOC is the main party to blame here, for selling exclusive television rights in the first place. They're the ones who are supposed to uphold the Olympic tradition.
It all depends on the numbers. If there is 5% less traffic in that week, they'll ignore it. If there is 50% less traffic, they might take notice.
Also, unlike most boycotts, this protest is not against an unpopular corporate policy, but against the product itself. The beta interface has such poor usability that I can't see myself using it, even if I wanted to.
John Walker replied "I'll just fire myself for you now", so I think it's safe to say he has zero pull. But that was not my point. Asking for the publisher to be fired is saying "this should never have been published in the first place". I think it's telling that discussing copyright length provokes such a strong reaction.
As a result, his reaction to these kinds of comments is totally unsurprising.
Disagreeing with an editorial piece is fine, even if the motivation behind it might be self-serving, but asking for whoever published it to be fired is completely unreasonable, in my opinion.
If you want to make it a fair test, only 20 year old content should be included. Unfortunately, despite their "PC Gaming since 1873" slogan, they haven't been around for that long.
Lasers might be safer than bullets, since bullets always land somewhere, while lasers disperse in space if you take care in what direction you fire them in.
Indeed. The problem KDE 4.0 had was that compared to the very polished 3.10 series, 4.0 was incomplete and buggy. This was a problem with the implementation however, not with the design. This is very different to the GNOME and Unity situations, where a lot of users didn't agree with the design decisions.
A project specifically about finding undefined behavior is STACK. It didn't find any problems on the two projects I tried it on, but one of those is rather small and the other is pretty mature, so maybe most of the undefined behavior has been fixed already.
Just setting the warning levels a bit higher ("-Wall -Wextra" in GCC; despite the name "-Wall" doesn't actually enable all warnings) will already help a lot in spotting potentially dangerous constructs.
Also useful is Clang's analyzer mode ("clang --analyze"), maybe not so much for undefined behavior, but it did find a few cases of wrong pointer use (such as a potential null pointer dereference) in code I tried it on.
For C++ there is also Cppcheck, which is good at finding potential problems related to classes, for example data members that are not initialized by a constructor: initialization of class types is enforced, but C++ does allow data members of primitive types to be uninitialized after construction, for some reason.
Meanwhile, electronics in each cabinet costs approximately $50,000 but only serves approximately 12 customers/ cabinet, and EBTC says they have updated original components twice bringing total investment to $150,000 for each cabinet, bringing the grand total (for16 cabinets) to $2,400.000.
So they probably bought equipment that could serve a few hundred customers but since there don't live that many people within range, only a dozen are connected. Did they make the wrong purchase decisions or does the equipment that fits their needs simply not exist?
Well, I know the difference between the Enterprise Edition and applets, but the last time I did any work with Java EE was at the time EJB 2.0 was still new. All I can do is confirm that those interfaces required a lot of boilerplate to use: so much that we used JavaDoc plugins to generate the code for us. Someone told me that later Java EE versions are more usable, but I don't have personal experience with that; I spent the next few years doing a web app in Python instead.
Many companies are generating huge profits; they don't need to raise prices and risk becoming uncompetitive. Those profits are currently used to for example pay dividends to shareholders and do acquisitions, which benefits a small number of people.
Sharing the wealth doesn't mean handing out money to whoever holds out their hands, it means having all people who were involved in creating the wealth benefit from it. If a company only sees its workers as "human resources", then "what they are worth" is the lowest possible price it can hire those resources for. If it sees itself and the workers as participants in a social structure, it can give them a fair share of the income the company generated.
One difference is that if you drop privileges, you cannot regain them, while capabilities can be passed from one process to another. For example, if a web site asks for access to your web cam, it would be good if the user can allow or deny that on a case-by-case basis. With capabilities, the capability to access the web cam can be transferred to the tab sandbox that asked for it. With privilege separation, you'd either have to give all sandboxes the ability to access the web cam, thus risking exploited tabs accessing it, or deny all sandboxes access and build some kind of inter-process mechanism for web cam access, which is a lot of work and (if it contains bugs) could provide a way for code to escape from the sandbox.
But even if you only look at scenarios with static policies, I think enumerating allowed actions is different from setting rules. If you'd model "things your process can do" as integers, you'd have a set of integers describing what your process is allowed to do. Dropping privileges is like saying "remove all even numbers from the set" followed by "remove all prime numbers from the set", while using capabilities is like saying "the new set is { 5, 42, 83 }".
To kill someone with a knife, you have to stand very close to them and thrust the weapon into their body. To kill them with a gun, they have to be in line of sight and pull the trigger. To kill them with a drone, you need them on live camera and push a button. To kill them with an autonomous robot, you need to have a description of what they look like and what area they are located in and program that into the robot. Every step becomes more indirect, more emotionally detached.
"Guns don't kill people" is just a slogan. A gun is a tool. For killing people. The real questions include "Do guns deter crime or make it more violent?" and "Does home gun ownership help prevent a government from turning on its own people?", but those have no simple answers, so they are not as useful in propaganda.
What I understood from the presentation is that in Capsicum your process starts to run with traditional access control. You acquire the capabilities you'll need and then you switch into a different mode in which resources can only be accessed using capabilities. In other words, you drop all possible operations at once, not a selected subset. Except when using capabilities you acquired in advance or were given by a different (sub-)process, you can do nothing at all with resources.
The word "capability" is a bit counter-intuitive here. As the AC below says, think of it as a handle, not a privilege.
Dropping privileges means that the application (or one of its sub-processes) gives up the ability to perform a certain class of operations, such as switching user ID, binding to ports below 1024 etc. This is already done in a lot of networking applications. If I understood it correctly, using capabilities means that you cannot perform an operation unless you have some kind of token (such as a file descriptor) that represents the resource and the type of access you're allowed on that resource.
So instead of dropping the privilege to write files at all, which would not be feasible in many applications, you would have a file descriptor to a directory that allows writing files under that directory. Creating new file descriptors from path strings would be blocked; the only way to get new file descriptors is from existing ones and the new descriptors will have the same or less rights than the ones they were derived from.
It's tremendously awkward to tell someone that you should buy two copies of the expansion just to get a second 90.
A bit of searching shows that in the past WoW expansions were introduced at $40, so why wouldn't a player opt to buy the expansion twice rather than buying the level upgrade for a second character?
Note that the pricing for this expansion hasn't been published yet, but I doubt they're going to price it at $60, since people expect a full game for that price.
Indeed there is no such thing as secure self-destructing messages. What is more interesting is end-to-end encryption, where you can at least ensure that no-one except the recipient can open the message.
And when the largest Dutch telco announced plans to charge extra for the "privilege" of being able to use IM or VOIP on a mobile data plan, net neutrality legislation was passed in record time.
Right now the arctic ocean and Hudson Bay are 100% frozen due to this thing we call winter. Summer it is a different story.
The summer story is much more relevant though. In winter, when there is a low angle sun a few hours a day, sunlight is reflected back into space. In summer, when the sun is at a higher angle and there are only a few hours of night a day, increasingly large areas are not reflecting much sunlight back into space. I don't see how this invalidates TFA.
But don't forget that big pharma, for all its problems still is the number one creator of new drugs. In 2012 alone, the U.S. government and private companies spent a combined $130 billion (PDF) on medical research.
Ahh, very large numbers without context.
There is a little context:
Last year Novartis lost a six-year legal battle after the Indian Supreme court ruled that small changes and improvements to the drug Glivec did not amount to innovation deserving of a patent.
So some of that research is being spent on patentable variations rather than better cures, which is a waste of time and money when looking at the complete healthcare system. Commercial research also produces actually useful drugs, but perhaps it would be more efficient to let governments lead the research and let pharma companies handle the production side.
If NBC buys television rights for billions of dollars, of course they're going to use those to make money in any way they can. In my opinion the IOC is the main party to blame here, for selling exclusive television rights in the first place. They're the ones who are supposed to uphold the Olympic tradition.
It all depends on the numbers. If there is 5% less traffic in that week, they'll ignore it. If there is 50% less traffic, they might take notice.
Also, unlike most boycotts, this protest is not against an unpopular corporate policy, but against the product itself. The beta interface has such poor usability that I can't see myself using it, even if I wanted to.
John Walker replied "I'll just fire myself for you now", so I think it's safe to say he has zero pull. But that was not my point. Asking for the publisher to be fired is saying "this should never have been published in the first place". I think it's telling that discussing copyright length provokes such a strong reaction.
As a result, his reaction to these kinds of comments is totally unsurprising.
Disagreeing with an editorial piece is fine, even if the motivation behind it might be self-serving, but asking for whoever published it to be fired is completely unreasonable, in my opinion.
If you want to make it a fair test, only 20 year old content should be included. Unfortunately, despite their "PC Gaming since 1873" slogan, they haven't been around for that long.
Lasers might be safer than bullets, since bullets always land somewhere, while lasers disperse in space if you take care in what direction you fire them in.
Both the iPod and the iPhone arrived pretty late in their respective markets.
Indeed. The problem KDE 4.0 had was that compared to the very polished 3.10 series, 4.0 was incomplete and buggy. This was a problem with the implementation however, not with the design. This is very different to the GNOME and Unity situations, where a lot of users didn't agree with the design decisions.
Have you tried "from __future__ import antigravity"?
A project specifically about finding undefined behavior is STACK. It didn't find any problems on the two projects I tried it on, but one of those is rather small and the other is pretty mature, so maybe most of the undefined behavior has been fixed already.
Just setting the warning levels a bit higher ("-Wall -Wextra" in GCC; despite the name "-Wall" doesn't actually enable all warnings) will already help a lot in spotting potentially dangerous constructs.
Also useful is Clang's analyzer mode ("clang --analyze"), maybe not so much for undefined behavior, but it did find a few cases of wrong pointer use (such as a potential null pointer dereference) in code I tried it on.
For C++ there is also Cppcheck, which is good at finding potential problems related to classes, for example data members that are not initialized by a constructor: initialization of class types is enforced, but C++ does allow data members of primitive types to be uninitialized after construction, for some reason.
Are US pizzas actually 1 foot in radius or did the person who answered that mix up radius and diameter?
Also from TFA:
Meanwhile, electronics in each cabinet costs approximately $50,000 but only serves approximately 12 customers/ cabinet, and EBTC says they have updated original components twice bringing total investment to $150,000 for each cabinet, bringing the grand total (for16 cabinets) to $2,400.000.
So they probably bought equipment that could serve a few hundred customers but since there don't live that many people within range, only a dozen are connected. Did they make the wrong purchase decisions or does the equipment that fits their needs simply not exist?
Well, I know the difference between the Enterprise Edition and applets, but the last time I did any work with Java EE was at the time EJB 2.0 was still new. All I can do is confirm that those interfaces required a lot of boilerplate to use: so much that we used JavaDoc plugins to generate the code for us. Someone told me that later Java EE versions are more usable, but I don't have personal experience with that; I spent the next few years doing a web app in Python instead.
Many companies are generating huge profits; they don't need to raise prices and risk becoming uncompetitive. Those profits are currently used to for example pay dividends to shareholders and do acquisitions, which benefits a small number of people.
Sharing the wealth doesn't mean handing out money to whoever holds out their hands, it means having all people who were involved in creating the wealth benefit from it. If a company only sees its workers as "human resources", then "what they are worth" is the lowest possible price it can hire those resources for. If it sees itself and the workers as participants in a social structure, it can give them a fair share of the income the company generated.
One difference is that if you drop privileges, you cannot regain them, while capabilities can be passed from one process to another. For example, if a web site asks for access to your web cam, it would be good if the user can allow or deny that on a case-by-case basis. With capabilities, the capability to access the web cam can be transferred to the tab sandbox that asked for it. With privilege separation, you'd either have to give all sandboxes the ability to access the web cam, thus risking exploited tabs accessing it, or deny all sandboxes access and build some kind of inter-process mechanism for web cam access, which is a lot of work and (if it contains bugs) could provide a way for code to escape from the sandbox.
But even if you only look at scenarios with static policies, I think enumerating allowed actions is different from setting rules. If you'd model "things your process can do" as integers, you'd have a set of integers describing what your process is allowed to do. Dropping privileges is like saying "remove all even numbers from the set" followed by "remove all prime numbers from the set", while using capabilities is like saying "the new set is { 5, 42, 83 }".
To kill someone with a knife, you have to stand very close to them and thrust the weapon into their body. To kill them with a gun, they have to be in line of sight and pull the trigger. To kill them with a drone, you need them on live camera and push a button. To kill them with an autonomous robot, you need to have a description of what they look like and what area they are located in and program that into the robot. Every step becomes more indirect, more emotionally detached.
"Guns don't kill people" is just a slogan. A gun is a tool. For killing people. The real questions include "Do guns deter crime or make it more violent?" and "Does home gun ownership help prevent a government from turning on its own people?", but those have no simple answers, so they are not as useful in propaganda.
What would you do when you run out of robots? Do you surrender or do you keep fighting?
What I understood from the presentation is that in Capsicum your process starts to run with traditional access control. You acquire the capabilities you'll need and then you switch into a different mode in which resources can only be accessed using capabilities. In other words, you drop all possible operations at once, not a selected subset. Except when using capabilities you acquired in advance or were given by a different (sub-)process, you can do nothing at all with resources.
The word "capability" is a bit counter-intuitive here. As the AC below says, think of it as a handle, not a privilege.
Dropping privileges means that the application (or one of its sub-processes) gives up the ability to perform a certain class of operations, such as switching user ID, binding to ports below 1024 etc. This is already done in a lot of networking applications. If I understood it correctly, using capabilities means that you cannot perform an operation unless you have some kind of token (such as a file descriptor) that represents the resource and the type of access you're allowed on that resource.
So instead of dropping the privilege to write files at all, which would not be feasible in many applications, you would have a file descriptor to a directory that allows writing files under that directory. Creating new file descriptors from path strings would be blocked; the only way to get new file descriptors is from existing ones and the new descriptors will have the same or less rights than the ones they were derived from.