What if you're running two applications that both are capable of monopolizing all your cpu time?
How often does this actually occur? And if it does and the processes are threaded, won't a smart OS scheduler just migrate the threads so that each application essentially has a CPU (or four) to itself?
I think the big win is more likely that this makes threading on Mac easier. That said, I really hate the way they did this; putting high-level language features like lexical closures in C is just ugly. C is a glorified assembler, and should stay that way:-)
Why do you think cooperative threads inefficient? Is it because people use them inefficiently?
Cooperative threads, when used correctly, are more efficient than pre-emptive because with pre-emptive, you have to save and restore all state to context switch (kernel preempts a process, and doesn't know which registers are in use, so has to save them all). With cooperative, you can context switch at function boundaries and not have to save the callee-save registers.
In fact, since you're setting a standard, I'll homeschool my first daughter and send the second to public school, then we compare results. If I do better than the state, I can sue. I'll even guarantee that neither daughter gets an advantage in time spent on their education, or that we spend less time teaching my homeschooled daughter.
It's only fair that I can sue the state for using my tax money to educate children poorly, if they could sue me for the same.
I'm as pro-competition and free market as anybody, but contracts just don't work that way. Much of the work is so specialized that only one company is able to fulfill the contract. For example, Northrop Grumman is the ONLY company that is able to overhaul aircraft carriers, so they get every contract. The barrier to entry is impossibly high for potential competitors. The contract is so large that it essentially grants a monopoly to the winner. The losers can't stay in business long enough to compete.
The contracts are also massive. The contractors aren't competing to supply welding materials, they're competing for things like, "overhaul this aircraft carrier and replace the reactors," that are pretty much written so that one company is guaranteed to be awarded the contract. It's a happy coincidence that those companies have high-level officers who have plenty of buddies in D.C. and factories in as many key congressional districts as possible.
This is a best-case scenario, assuming there are no back-room deals and shady hook-ups going on, which would be a miracle.
That's an imposter. RMS would never use libjpeg when he can just mail a hard copy of the binary out to an assistant who will send him a photograph back.
If there's one thing worse than the government doing something, it's the government giving someone a de-facto monopoly to do it in the form of a government contract.
Contracting is the new graft. Witnessing this from the DoD side of the house, the same thing happens over and over. High level military officer retires, joins or starts a contracting company, and convinces everyone the contractor can do what the government is already doing for much cheaper. Politicians decide to use contractors, costs escalate, and there is no alternative because the formerly home-grown expertise is gone, since all the government experts are now working for the contractor making double for the same job.
Having this strong domestic industry does more for Japan's economy as a whole than would having the slightly cheaper cars that the lack of tariffs would have permitted.
You state that as a fact, but it's simply not true. How do you know what effect having cheaper cars would have had on Japan's economy? For every dollar (or yen) Japan spent on buying cars at unnecessarily high prices, that's money that could have been used for something else more productive.
You seem to think that a tariff increases the efficiency of the Japanese economy. If that's true, then why not double, triple, or quadruple it? By your logic, since the auto industry is a greater benefit to Japan's economy than other possible uses of their money, they should raise the tariff to infinity and reap the rewards.
Let's see what that would do...an infinite tariff would essentially mean that it's illegal to buy foreign cars in Japan, strengthening their industry. But why stop there? How about individual cities in Japan enact their own tariffs to protect local auto manufacturing? How about individual car dealerships? What if individual car dealerships were required to produce their own cars from scratch?
Well, you might say, that's ridiculous, the price of a car would skyrocket and cars would be prohibitively expensive in Japan, so that transportation would be inordinately expensive and damage the economy as a whole. The only beneficiaries would be the individual car dealerships; the rest of the economy would suffer.
And that's true of nations just as much as it is of individuals; restrictions on trade are an opportunity cost that prevents more efficient uses of that capital.
Learn Lisp. You could write all that with a few macros and have time left over before lunch to read all of Paul Graham's essays and think about how awesome you are.
There's no need to worry about what the libraries are doing, or whether the call to some function is going to cause side effects or something you didn't intend, or whether some compiler quirk is going to make your code take ten times longer to run.
Why not? Because you're not going to link against any libraries? Assembly lets you do that; and you can also not use libraries when using C.
I've looked at plenty of optimized C compiler output and it's fairly tight with a recent compiler. You're not going to get much more performance out of it, and you're probably not CPU bound on any problems anyway, so saving instructions probably will result in a very little performance increase when your bottleneck is main memory.
The "brownout scenarios" assumes that the data centers are a large portion of the overall electrical load, which is unlikely.
Even if they were, causing brownouts in the place where would be counterproductive for Google et. al., so I'd seriously doubt they'd adopt a system where they were taking out their own servers' power source. But that's beside the point; prices aren't low at times of peak usage, so this problem wouldn't exist by definition of the way the system works. This system would help drive traffic away from heavily-loaded localities.
The data center has to exist already and is already using electricity. The amount of electricity used is (the researchers are assuming) based on an unplanned proximity protocol; if I'm close to the server, that's the server my traffic gets routed to, regardless of price of electricity. With this system, Google can use electricity more efficiently at the cost of slighlty higher latency to me, which I'm unlikely to notice.
Routing packets costs money in terms on bandwidth, which is how you indirectly pay for the router and electricity used to route your packets.
These costs can all be calculated. If I can use this system to save $40,000 on electricity by increasing my bandwidth cost by $10,000, that's a signal that using the system is more efficient than not using it.
In order for Google to use the electricity, they already have to have a datacenter in the location. So they are already "local customers" and are fully capable of of running their datacenter at full capacity.
This isn't some magic way to siphon electricity from grandma's house. All it says is that google will turn off datacenters when the price goes up. This could actually save you from a brownout if Google uses a large percentage of electricity in your locality (doubtful, their usage probably is noise when compared to EVERYONE else); if the electricity provider can't keep up with demand they would raise prices and Google's data center would shut down.
That's contrary to the point of the system, which is to route traffic to where electricity is cheapest. If prices go up, the traffic will be routed elsewhere, instantaneously. So if you're in the business of selling electricity, your incentive is to lower prices to attract additional demand when you can handle it.
Economies of scale tend to make things cheaper. I don't see why this would be any different.
It is a magic world, let me tell you. In my fantasy, I don't deem to tell people what they can or can't do with a gift I give them, because I believe that is rude and an imposition.
It's the difference between treating people by default like criminals who will stab you in the back at the first opportunity, and treating them with respect and decency.
I'm happy to treat others with the respect I'd like them to afford me. I think there was some philosopher who made a magic rule about this, but I forget what it's called.
Beyond that, I believe that people will want to use the superior product regardless of how it was produced, and I want to see what those products are. I'd rather compete on the merits of my work than by coercion.
He mentions it, but obviously doesn't understand hidden volumes and plausible deniability. Either would have saved the UK folks that refused to give passwords away.
So the encrypted data can be identified as a plain English text document.
That's incorrect. If what you said was true, no encryption would work. For a good algorithm, the encrypted data is (feasibly) indistinguishable from random noise.
Imagine if my algorithm to encrypt files was to create a duplicate size set of random bits (essentially a one-time pad) and XOR it with my source file. Now I have essentially two sets of random data from all apperances. My only problem is that if I store both of these in the same place, an attack such as the one you described could work, because I can XOR all the data by the source, and eventually out comes the key, despite the fact that the data appears random.
Alternately I could XOR blocks of data by each other, (similar to convolution) and eventually out would pop the source document from the random noise.
However, all I have to do is shuffle these two sets of data around a little bit, say using a hashing algorithm, to make your attack infeasible.
By the way, I'm not saying that this is how Truecrypt works, but it's an example of how it's possible to encrypt something and make it appear random.
You can have a hidden partition WITHIN the encrypted partition. It's impossible to prove it's there. So you give the password, complying with the law, and say, "Yeah, I encrypted these documents because they have personal data on them."
Now what? They say that you must have another password? Based on what? It's impossible to prove, and you've ostensibly cooperated every step of the way.
In effect, you can encrypt some stuff, and encrypt another volume with a different password. The second volume is indistinguishable from random data, so if you give the password to the first volume, there is no way to prove that you are witholding anything.
They also offer hidden volumes within encrypted volumes for the same reason. There's no way to ever prove that a person has withheld ALL of the passwords, or that any data even exists in that space.
Slashdot Mirror
What if you're running two applications that both are capable of monopolizing all your cpu time?
How often does this actually occur? And if it does and the processes are threaded, won't a smart OS scheduler just migrate the threads so that each application essentially has a CPU (or four) to itself?
I think the big win is more likely that this makes threading on Mac easier. That said, I really hate the way they did this; putting high-level language features like lexical closures in C is just ugly. C is a glorified assembler, and should stay that way :-)
Why do you think cooperative threads inefficient? Is it because people use them inefficiently?
Cooperative threads, when used correctly, are more efficient than pre-emptive because with pre-emptive, you have to save and restore all state to context switch (kernel preempts a process, and doesn't know which registers are in use, so has to save them all). With cooperative, you can context switch at function boundaries and not have to save the callee-save registers.
Any self-respected geek should be already keeping up to date with Apple advancements which are and will be impacting techology in the years to come.
Are you kidding? Just because the guy didn't know the latest buzzword for closures and first-class functions?
This isn't new. This is 70's-era ideas just barely making it to the mainstream in a shiny package.
Would you like to live near a Nuclear power plant?
Hell no, I want to live on my own tropical island.
But given that I have to live near some sort of power generation, I'd take nuclear over any other form of power generation, thanks.
Remember, there are no solutions, only trade-offs.
I'm in.
In fact, since you're setting a standard, I'll homeschool my first daughter and send the second to public school, then we compare results. If I do better than the state, I can sue. I'll even guarantee that neither daughter gets an advantage in time spent on their education, or that we spend less time teaching my homeschooled daughter.
It's only fair that I can sue the state for using my tax money to educate children poorly, if they could sue me for the same.
I think you might be misinformed. I installed 3.0 yesterday, and the option is still there.
Yeah, instead, we should stop using oil immediately and we won't have that problem.
I'm as pro-competition and free market as anybody, but contracts just don't work that way. Much of the work is so specialized that only one company is able to fulfill the contract. For example, Northrop Grumman is the ONLY company that is able to overhaul aircraft carriers, so they get every contract. The barrier to entry is impossibly high for potential competitors. The contract is so large that it essentially grants a monopoly to the winner. The losers can't stay in business long enough to compete.
The contracts are also massive. The contractors aren't competing to supply welding materials, they're competing for things like, "overhaul this aircraft carrier and replace the reactors," that are pretty much written so that one company is guaranteed to be awarded the contract. It's a happy coincidence that those companies have high-level officers who have plenty of buddies in D.C. and factories in as many key congressional districts as possible.
This is a best-case scenario, assuming there are no back-room deals and shady hook-ups going on, which would be a miracle.
That's an imposter. RMS would never use libjpeg when he can just mail a hard copy of the binary out to an assistant who will send him a photograph back.
If there's one thing worse than the government doing something, it's the government giving someone a de-facto monopoly to do it in the form of a government contract.
Contracting is the new graft. Witnessing this from the DoD side of the house, the same thing happens over and over. High level military officer retires, joins or starts a contracting company, and convinces everyone the contractor can do what the government is already doing for much cheaper. Politicians decide to use contractors, costs escalate, and there is no alternative because the formerly home-grown expertise is gone, since all the government experts are now working for the contractor making double for the same job.
Nobody wants to watch a game where they already know who will win. Likewise, the athletes don't want to compete in a contest they're sure to lose.
The continued existence of the Baltimore Orioles disproves your assertion.
Having this strong domestic industry does more for Japan's economy as a whole than would having the slightly cheaper cars that the lack of tariffs would have permitted.
You state that as a fact, but it's simply not true. How do you know what effect having cheaper cars would have had on Japan's economy? For every dollar (or yen) Japan spent on buying cars at unnecessarily high prices, that's money that could have been used for something else more productive.
You seem to think that a tariff increases the efficiency of the Japanese economy. If that's true, then why not double, triple, or quadruple it? By your logic, since the auto industry is a greater benefit to Japan's economy than other possible uses of their money, they should raise the tariff to infinity and reap the rewards.
Let's see what that would do...an infinite tariff would essentially mean that it's illegal to buy foreign cars in Japan, strengthening their industry. But why stop there? How about individual cities in Japan enact their own tariffs to protect local auto manufacturing? How about individual car dealerships? What if individual car dealerships were required to produce their own cars from scratch?
Well, you might say, that's ridiculous, the price of a car would skyrocket and cars would be prohibitively expensive in Japan, so that transportation would be inordinately expensive and damage the economy as a whole. The only beneficiaries would be the individual car dealerships; the rest of the economy would suffer.
And that's true of nations just as much as it is of individuals; restrictions on trade are an opportunity cost that prevents more efficient uses of that capital.
Eh, at least you have a clean floor. I wish my wife would mop.
Learn Lisp. You could write all that with a few macros and have time left over before lunch to read all of Paul Graham's essays and think about how awesome you are.
There's no need to worry about what the libraries are doing, or whether the call to some function is going to cause side effects or something you didn't intend, or whether some compiler quirk is going to make your code take ten times longer to run.
Why not? Because you're not going to link against any libraries? Assembly lets you do that; and you can also not use libraries when using C.
I've looked at plenty of optimized C compiler output and it's fairly tight with a recent compiler. You're not going to get much more performance out of it, and you're probably not CPU bound on any problems anyway, so saving instructions probably will result in a very little performance increase when your bottleneck is main memory.
The "brownout scenarios" assumes that the data centers are a large portion of the overall electrical load, which is unlikely.
Even if they were, causing brownouts in the place where would be counterproductive for Google et. al., so I'd seriously doubt they'd adopt a system where they were taking out their own servers' power source. But that's beside the point; prices aren't low at times of peak usage, so this problem wouldn't exist by definition of the way the system works. This system would help drive traffic away from heavily-loaded localities.
The data center has to exist already and is already using electricity. The amount of electricity used is (the researchers are assuming) based on an unplanned proximity protocol; if I'm close to the server, that's the server my traffic gets routed to, regardless of price of electricity. With this system, Google can use electricity more efficiently at the cost of slighlty higher latency to me, which I'm unlikely to notice.
Routing packets costs money in terms on bandwidth, which is how you indirectly pay for the router and electricity used to route your packets.
These costs can all be calculated. If I can use this system to save $40,000 on electricity by increasing my bandwidth cost by $10,000, that's a signal that using the system is more efficient than not using it.
In order for Google to use the electricity, they already have to have a datacenter in the location. So they are already "local customers" and are fully capable of of running their datacenter at full capacity.
This isn't some magic way to siphon electricity from grandma's house. All it says is that google will turn off datacenters when the price goes up. This could actually save you from a brownout if Google uses a large percentage of electricity in your locality (doubtful, their usage probably is noise when compared to EVERYONE else); if the electricity provider can't keep up with demand they would raise prices and Google's data center would shut down.
That's contrary to the point of the system, which is to route traffic to where electricity is cheapest. If prices go up, the traffic will be routed elsewhere, instantaneously. So if you're in the business of selling electricity, your incentive is to lower prices to attract additional demand when you can handle it.
Economies of scale tend to make things cheaper. I don't see why this would be any different.
/dev/null is obstinate, not evil. The real evil responds with:
[question] is not recognized as an internal or external command,
operable program or batch file.
It is a magic world, let me tell you. In my fantasy, I don't deem to tell people what they can or can't do with a gift I give them, because I believe that is rude and an imposition.
It's the difference between treating people by default like criminals who will stab you in the back at the first opportunity, and treating them with respect and decency.
I'm happy to treat others with the respect I'd like them to afford me. I think there was some philosopher who made a magic rule about this, but I forget what it's called.
Beyond that, I believe that people will want to use the superior product regardless of how it was produced, and I want to see what those products are. I'd rather compete on the merits of my work than by coercion.
He mentions it, but obviously doesn't understand hidden volumes and plausible deniability. Either would have saved the UK folks that refused to give passwords away.
So the encrypted data can be identified as a plain English text document.
That's incorrect. If what you said was true, no encryption would work. For a good algorithm, the encrypted data is (feasibly) indistinguishable from random noise.
Imagine if my algorithm to encrypt files was to create a duplicate size set of random bits (essentially a one-time pad) and XOR it with my source file. Now I have essentially two sets of random data from all apperances. My only problem is that if I store both of these in the same place, an attack such as the one you described could work, because I can XOR all the data by the source, and eventually out comes the key, despite the fact that the data appears random.
Alternately I could XOR blocks of data by each other, (similar to convolution) and eventually out would pop the source document from the random noise.
However, all I have to do is shuffle these two sets of data around a little bit, say using a hashing algorithm, to make your attack infeasible.
By the way, I'm not saying that this is how Truecrypt works, but it's an example of how it's possible to encrypt something and make it appear random.
You can have a hidden partition WITHIN the encrypted partition. It's impossible to prove it's there. So you give the password, complying with the law, and say, "Yeah, I encrypted these documents because they have personal data on them."
Now what? They say that you must have another password? Based on what? It's impossible to prove, and you've ostensibly cooperated every step of the way.
Truecrypt solves this problem: Plausible Deniability
In effect, you can encrypt some stuff, and encrypt another volume with a different password. The second volume is indistinguishable from random data, so if you give the password to the first volume, there is no way to prove that you are witholding anything.
They also offer hidden volumes within encrypted volumes for the same reason. There's no way to ever prove that a person has withheld ALL of the passwords, or that any data even exists in that space.