You need all that stuff because you have a lot of little workloads that must all remain available. Don't misunderstand me, by little I mean less than a terabyte. If you lose one drive in a LUN, it's all hands on deck to get the leak plugged before a second drive fails and the CFO loses his SAP reporting database. These guys have one huge storage farm with thousands of drives that can tolerate a hundred drives failing without missing a beat. Why would they buy Sun gear if they designed the system to tolerate massive failures? More generally, why choose a fragile design supported by great storage when you can go with a great design built on redundant crap storage for one tenth the cost?
What EMC and Sun need to realize is that as cloud computing technology starts to trickle down to the Enterprise, reliable storage is going to become an unnecessary luxury. The new distributed world will be designed to deal with whole systems coming and going from the cloud. The good news for them is that we are at least ten years from this stuff making a dent in the corporate world.
They don't do business the same way you do. If the monitoring tool shows a pod with 2 drives down, they just ignore it. Two RAID arrays out and they might replace it. When all three go, they pull the pod and replace with a new one. Then they scavenge the carcass for parts. The magic is in the software. They don't simply save files on servers, they have software that manages where things are stored and stores everything in multiple places.
To give some perspective, at your stated one or two percent failure rate per month, a 45 drive pod would last over a year before all three RAID 6 arrays were likely to have failed. Just "refresh" the dead drives in each pod every three months and the likelihood of actually losing a whole pod is miniscule.
In their world, a drive failure is a non-event. An array failure is an "indicator of possible proplems". A pod failure is a reason to schedule it for maintenance tomorrow. The only thing that might get them to sweat is if they lost 10% of their boxes simultaneously.
There are two ways to run a reliable business. Either buy expensive reliable stuff and watch it like a hawk, or buy cheap stuff and make it redundant and self-healing.
Mike Willmon's budget was about $30K to convert his Pinto into an electric dragster. You could easily add a twin turbo kit, a bit of nitrous, and a bunch of driveline parts to a vintage Camaro or Chevelle and stay way under that number, and run 10s or 11s in the quarter mile. Mike expects 12s out of his Pinto.
My original point was that accellerating as fast as a million dollar supercar isn't a big deal. Straight line acceleration isn't what you are buying for $1,000,000.00. Anybody with $30K can embarass a Ferrari stoplight to stoplight. I'll bet the Pinto also has better windsheild wipers than a 60 foot Yacht and is oranger than a 2 billion dollar stealth bomber.
Judging a Ferrari Enzo by only its zero to 60 time is shortchanging the car. Mike Willmon's Pinto is also almost as fast as a fresh off the showroom floor $9,000 motorcycle. The Pinto is also faster than a ten-million-dollar Fabergé Egg thrown by Randy Johnson.
Always undersell and overdeliver. Starting a conversation about electric cars by comparing one to a supercar can only backfire.
I do have one problem with the plot. The fluid that turned out to be fuel turns anything it touches into an alien. I'd buy a fluid that is used to transform something into an alien or a fluid that is a potent fuel, but it doesn't make any sense for the fluid to be both. It's not like faster than light travel where it has to be introduced unexplained because the plot requires it, there would have been a ton of ways to fix this glaring plot hole.
Counter steering and gyroscopic forces are entirely different things. Counter steering would exist even if the wheel were designed in such a way to eliminate all gyroscopic effects (think a wheel-in-a-wheel design with the inner wheel turning the opposite direction and being heavier). Sure, in the real world, gyroscopic forces exist, but they are not necessary for counter steering.
GoldMine 6.5 doesn't run on Vista. An upgrade to GoldMine 8 costs almost $1000 per desktop. That's why a customer of mine won't switch to Vista. They could give out Vista for free with a $500 gift certificate for food and it would be a bad deal for him. There's a ton of small companies in similar situations all over the world.
I have my own problems with Vista, a lot of my fifteen years of "magic batch files" that do the automation for our training lab don't run on Vista due to UAC. Sure, I can reimplement them as MSI files and distribute them via some fancy system like Active Directory or Altiris, but they work fine today on XP. My labor for reimplementing them would probably cost around three grand.
When these encryption schemes are broken, it is rarely due to an underlying flaw in the encryption algorithm. It is almost always due to poorly secured local secrets or implementation details in the key management system.
Remember, the box sitting in your living room can decrypt the satellite signal. All you have to do is reverse engineer it and duplicate its functionality. If physical security is bad enough, you may not even have to understand it, just dump the eeprom contents and run the program on another device or emulator.
I live in Lockport. Over the past twenty years, I have probably missed four days of work due to weather. When the northeast was blacked out in 2003, south Lockport had power. When the city of Buffalo got 24 inches of snow in a few hours and shut down in 2000, the northtowns were snow-free. When the whole Western New York area had serious power problems from an early snow fall while the leaves were still on the trees back in October of 2006, my neighborhood in Lockport was unaffected. Our Cincinnati office seems to be closed at least twice a years for wind or ice storms. South of Buffalo gets a lot of snow, but we get about half as much in the north.
I have worked 30 miles from home since March 2007 and I don't know how to fill out a "snow day" on my time sheet because I've never needed to.
Since someone already jumped on the argument that C# is as good a high level language as any, I'll jump on the low level argument. C# is actually a good language for most application, even if they have a smattering of low level sections. I wouldn't write a device driver in C#, but I would write an image processing application in C#. One of the nifty features of C# is to admit that it isn't perfect for everything and it allows in-line C. So, instead of throwing away a high-level language for the 90% of an application that can benefit from it, simply write the application in C# and implement the 10% that would be better written in C, in C embedded directly in C#.
Microsoft wrote its libraries in.Net for many reasons. One of the bigger reasons people use.Net is for its security and memory management model. C libraries wouldn't honor either of these. Also, consider a C function that returns a string (well, conceptually since it can't literally return a string). Either the caller has to pass a reference to a buffer that the function then fills, or the function has to allocate a properly sized buffer and return a reference to it. In the first case, that would force C# to use C's memory allocation rules (yes, C has rules, like you have to actually know the address and it can't be moved). In the second case, it would force the function and the app to agree on a memory management scheme. The chosen scheme would be guaranteed to be more difficult to use than the C# native scheme.
Also, C# isn't VB with curly braces. VB.Net is C# without curly braces. There is an important distinction. I have been around as many VB6 programmers transitioned to VB.Net. It is always a difficult process because almost none of the techniques necessary to write good VB.Net code are known to VB6 programmers because the features are new to VB.Net.
Finally, quick to compile is only important for those developing in Visual Studio. VS gives a lot of help and does a lot of reflection on the current code to give very specific help. VB.Net essentially incrementally recompiles the application every time you hit enter and in C# it is important to recompile often to keep intellisense up to date.
Exactly what did you do to earn those dollars from the performance in Poland? Had they not played the music, would you have more free time to be with your family or to produce more music? Don't get me wrong, I'm for the fair compensation of artists. However, I believe that society should choose to provide incentives for artists to continue producing works of art. This is a willfull decision to give people a means to live (money) even though they don't produce anything that is physically valuable to society. It is a gift. You seem to believe that that money was rightfully owed to you and copyright law only serves to clarify that fact. The right to be free is natural, the right to be payed for music is not.
The public tide is turning. If you guys don't act a bit more gracious and keep letting these ruthless organizations do your dirty work, the people of the world may decide you are not worth the investment and go back to the old "patron of the arts" model where you get to be some rich guy's live-in artist.
I do some maintenance development. It takes me ten times as long to fix, test, and deploy an application than it does to fix the data corruption that results from the crash that the bug causes. However, by our metrics, one hundred data fixes per month is guaranteed to keep me under my SLA no matter how many other problem I solve slowly. If I ever choose to fix the issue, my SLA compliance will go into the toilet both because fixing it takes longer than the SLA and because I no longer get to log easy fixes. Some organizations fix the first problem by allowing fixes under a process with a different SLA, but no one can fix the second problem. I simply don't want this problem fixed ever.
If I were doing a good job, the problems that come up should be all be first-timers. Any issue should be root-caused and fixed before it becomes recurring. This implies that a healthy organization will have longer ticket close times than a broken organization. Anybody who's problem resolution times are going down has given up on fixing the underlying cause.
Actual example -- my company is now putting in password reset self-service. This is a huge win for the whole company (except for the security guys, they lost that argument). However, this is likely to increase the average ticket close time for level 1.
http://www.channelinsider.com/c/a/Solution-Builder/We-Did-Nothing-Wrong-Why-Software-Quality-Matters/
21 people died due to a software error. The doctors that administered the doses were indicted for murder (I don't know the outcome), the software vendor was sued, but the developers were not personally held accountable. This one is interesting, because if the software had been built by an engineering firm and they had an licensed Professional Engineer stamp the design, he would have been held accountable.
More specifically, an Engineer is someone who can claim that a system won't kill people and can legally transfer the responsibility for the lives of the users from the construction company to himself. What we don't have in the software industry is the accountability that forces Engineers to be rigorous. Sure, we software developers can claim that we use rigorous processes, but every time something doesn't work, we shrug it off and get to work on the fix. If a real Engineer screws up big just once, he loses his license and/or goes to jail.
What makes licensed Professional Engineers so mad about the computer industry's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life. Don't think of an Engineer as someone who is good at any specific thing, think about them as a gatekeeper of the use of technology in public places.
Or hack the authentication system so that it thinks you already went through all that stuff when all you did was forge an authentication proof. Their system is very resistant to some types of attacks, like password guessing. But, it is no stronger than a normal username and password against most attacks on the system itself. SrongWebmail.com's biggest mistake was thinking that they knew of all of their weaknesses.
You're a moron. Torque is only a useful measurement if you fix all of the other variables. Horsepower is always a useful measurement.
Example: I can make an cheap Chinese corless drill make 1000 ft-lbs of torque simply by adding a reducing gear. 1000 ft-lbs of torque is only really meaningful if I first give the rpm at which that torque needs to be made. On the other hand, that Chinese drill is never going to make 1HP. Think of HP as the ability to create torque.
Oh.... I agree that 0-60 in 4 seconds is nothing to write home about. My streetbike does 0-60 in about 2.3 seconds. Gotta love 199.1 HP in a 400 pound package.
Engines are designed to approach detonation at peak load. At part-throttle cruising, where an engine will be 99% of the time in a fuel economy study, throttle vacuum and low thermodynamic loads will keep the engine far from the detonation point. No matter how low octane fuel you put in a vehicle, the knock sensor will not go off at cruise. So, any effect that ignition timing may have on the engine will not be a factor in fuel economy unless you drive it like a race car.
Small turbo engines are an exception, as they can keep cylinder pressure up even at low load. But all normally aspirated engines will not get better mileage from an octane level higher than they were designed for. Today's aluminum blocks and pistons can easily transfer all of the heat from the center of the piston at part throttle. Heck, if flame temperature was the primary issue, that could easily be taken care of with a colder spark plug.
BTW, using 100% ethanol to fuel our cars will not prevent us from importing oil for critical industries (other than the auto industry). So, no matter what we do, we will still have the same military expeditures to secure our access to oil. That's why it isn't factored into ethanol savings -- because we simply cannot live the way we do without imported oil.
Also, buying oil with US dollars, then taking those dollars back for CDOs backed by mortgages that were overvalued, was our way of buying oil with fake money. We pay real money for ethanol. Those dictators have oil, someone will always give them money for it.
Any study that shows high octane fuel giving better fuel consumption should be suspect immediately. Octane does not equate to energy content. High octane gas is also not "better gas". It does not reduce wear or carbon buildup. Higher octane fuel is simply more resistant to pre-detonation than lower octane fuel. Most of the time, it takes additives to make a fuel more detonation resistant and the additives reduce fuel efficiency.
Yea, but you also get the overhead of two schedulers (the host and the guest) and two systems moving thread context from core to core, which is an expensive operation. Most VMware systems are pretty heavily oversubsubscribed in terms of cores. Its not uncommon to have 60 guests on a 16 core host. If all 60 guests have 4 virtual CPUs, you do get the advantage that one guest can expand out to consume about a quarter of the total host CPU power, but you also have the cost of guest SMP switching even though you are using an average of 0.25 cores per guest.
He didn't say to use a single vCPU for a non-SMP aware app, he said to use a single vCPU for all application loads. For SMP aware apps, adding another virtual CPU is a scaling option. If you have non-SMP aware apps, then you need to find another solution, like migrate to a host with faster cores.
It makes sense. If you have 32 workloads and 16 cores, don't add the overhead of making 64 virtual vCPUs, 32 will use the host resources more efficiently as long as one app doesn't need the power of more than one core. If it does, give it to the guest only when it needs it.
I would only expect to make more because even at a higher price, I'd be among the low bidders. Mowing a difficult lawn isn't more expensive because it is more work, it is more expensive because no one will provide the service for a lower cost. This example doesn't illustrate the difference, but consider this--
If someone invented a lawn mowing system that was very cheap and could turn lawn mowing into a nearly effortless and fast operation, the work=money theory would lead to the conclusion that a professional lawn servicer would simply do more lawns in a day and make the same money for the same effort. In reality, lawn mowing would become an almost non-sellable service as most people would do it themselves. For the few professionals that remain, the price per unit of effort would go down because the potentially qualified pool of labor would be larger.
The book publishing industry has been like this for years, and with eBooks, is getting more so like this. Publishing was never very expensive, creation is. The payment isn't for the cost of creation, it is literally ransom for reading the content. The system only works this way because no one can think of a better one, not because it is supposed to work this way.
I am not saying that copyright is bad or that books should be free. I am simply pointing out that an author isn't entitled to be paid for their work by units of effort. We, as a society, have chosen to value their effort and have contrived a very flakey system to encourage authors to write. I'm sure we can do better and we should take every opportunity to look at alternative systems.
If your time is worth nothing, that is fine, but most people's time is more valuable than that.
So, a product is worth the time and effort put into it?
If I mowed your lawn with tweezers, would it be worth more than if I did it with a lawnmower? If I wrote a book that was the alphabet repeated six million times, all typed by hand, would it be worth anything? The "time is money" math only works on the producing end. If I could make $4 for an effort that takes two hours, I probably wouldn't do it. It doesn't automatically mean that if something takes time then it is worth money.
The idea of letting an author make money from an original work is a specific interference in the normal process of the economy by the government to try to entice production of such works. It is not a natural right or an entitlement.
Slashdot Mirror
You need all that stuff because you have a lot of little workloads that must all remain available. Don't misunderstand me, by little I mean less than a terabyte. If you lose one drive in a LUN, it's all hands on deck to get the leak plugged before a second drive fails and the CFO loses his SAP reporting database. These guys have one huge storage farm with thousands of drives that can tolerate a hundred drives failing without missing a beat. Why would they buy Sun gear if they designed the system to tolerate massive failures? More generally, why choose a fragile design supported by great storage when you can go with a great design built on redundant crap storage for one tenth the cost?
What EMC and Sun need to realize is that as cloud computing technology starts to trickle down to the Enterprise, reliable storage is going to become an unnecessary luxury. The new distributed world will be designed to deal with whole systems coming and going from the cloud. The good news for them is that we are at least ten years from this stuff making a dent in the corporate world.
They don't do business the same way you do. If the monitoring tool shows a pod with 2 drives down, they just ignore it. Two RAID arrays out and they might replace it. When all three go, they pull the pod and replace with a new one. Then they scavenge the carcass for parts. The magic is in the software. They don't simply save files on servers, they have software that manages where things are stored and stores everything in multiple places.
To give some perspective, at your stated one or two percent failure rate per month, a 45 drive pod would last over a year before all three RAID 6 arrays were likely to have failed. Just "refresh" the dead drives in each pod every three months and the likelihood of actually losing a whole pod is miniscule.
In their world, a drive failure is a non-event. An array failure is an "indicator of possible proplems". A pod failure is a reason to schedule it for maintenance tomorrow. The only thing that might get them to sweat is if they lost 10% of their boxes simultaneously.
There are two ways to run a reliable business. Either buy expensive reliable stuff and watch it like a hawk, or buy cheap stuff and make it redundant and self-healing.
Mike Willmon's budget was about $30K to convert his Pinto into an electric dragster. You could easily add a twin turbo kit, a bit of nitrous, and a bunch of driveline parts to a vintage Camaro or Chevelle and stay way under that number, and run 10s or 11s in the quarter mile. Mike expects 12s out of his Pinto.
... 26 grand and any vintage Chevy can do 9 seconds in the 1/4 mile. If you want to save a significant chunk of the budget and simply find a gas package with slightly better perfomance than Mike ... http://nelsonracingengines.com/pricesheets/chevy/dailydriver/na/dds_454bbc_na.pdf ... 12 grand for 625HP, plenty to beat the Pinto.
Here's a drop in package I found in two minutes of googling... http://nelsonracingengines.com/pricesheets/chevy/dailydriver/tt/dds_355_tt.pdf
My original point was that accellerating as fast as a million dollar supercar isn't a big deal. Straight line acceleration isn't what you are buying for $1,000,000.00. Anybody with $30K can embarass a Ferrari stoplight to stoplight. I'll bet the Pinto also has better windsheild wipers than a 60 foot Yacht and is oranger than a 2 billion dollar stealth bomber.
Judging a Ferrari Enzo by only its zero to 60 time is shortchanging the car. Mike Willmon's Pinto is also almost as fast as a fresh off the showroom floor $9,000 motorcycle. The Pinto is also faster than a ten-million-dollar Fabergé Egg thrown by Randy Johnson.
Always undersell and overdeliver. Starting a conversation about electric cars by comparing one to a supercar can only backfire.
I do have one problem with the plot. The fluid that turned out to be fuel turns anything it touches into an alien. I'd buy a fluid that is used to transform something into an alien or a fluid that is a potent fuel, but it doesn't make any sense for the fluid to be both. It's not like faster than light travel where it has to be introduced unexplained because the plot requires it, there would have been a ton of ways to fix this glaring plot hole.
Your self-admittedly crappy laptop has a larger screen than your work issued desktop? What did they give you to work on, a 13 inch CRT?
Counter steering and gyroscopic forces are entirely different things. Counter steering would exist even if the wheel were designed in such a way to eliminate all gyroscopic effects (think a wheel-in-a-wheel design with the inner wheel turning the opposite direction and being heavier). Sure, in the real world, gyroscopic forces exist, but they are not necessary for counter steering.
GoldMine 6.5 doesn't run on Vista. An upgrade to GoldMine 8 costs almost $1000 per desktop. That's why a customer of mine won't switch to Vista. They could give out Vista for free with a $500 gift certificate for food and it would be a bad deal for him. There's a ton of small companies in similar situations all over the world.
I have my own problems with Vista, a lot of my fifteen years of "magic batch files" that do the automation for our training lab don't run on Vista due to UAC. Sure, I can reimplement them as MSI files and distribute them via some fancy system like Active Directory or Altiris, but they work fine today on XP. My labor for reimplementing them would probably cost around three grand.
When these encryption schemes are broken, it is rarely due to an underlying flaw in the encryption algorithm. It is almost always due to poorly secured local secrets or implementation details in the key management system.
Remember, the box sitting in your living room can decrypt the satellite signal. All you have to do is reverse engineer it and duplicate its functionality. If physical security is bad enough, you may not even have to understand it, just dump the eeprom contents and run the program on another device or emulator.
I live in Lockport. Over the past twenty years, I have probably missed four days of work due to weather. When the northeast was blacked out in 2003, south Lockport had power. When the city of Buffalo got 24 inches of snow in a few hours and shut down in 2000, the northtowns were snow-free. When the whole Western New York area had serious power problems from an early snow fall while the leaves were still on the trees back in October of 2006, my neighborhood in Lockport was unaffected. Our Cincinnati office seems to be closed at least twice a years for wind or ice storms. South of Buffalo gets a lot of snow, but we get about half as much in the north.
I have worked 30 miles from home since March 2007 and I don't know how to fill out a "snow day" on my time sheet because I've never needed to.
Since someone already jumped on the argument that C# is as good a high level language as any, I'll jump on the low level argument. C# is actually a good language for most application, even if they have a smattering of low level sections. I wouldn't write a device driver in C#, but I would write an image processing application in C#. One of the nifty features of C# is to admit that it isn't perfect for everything and it allows in-line C. So, instead of throwing away a high-level language for the 90% of an application that can benefit from it, simply write the application in C# and implement the 10% that would be better written in C, in C embedded directly in C#.
Microsoft wrote its libraries in .Net for many reasons. One of the bigger reasons people use .Net is for its security and memory management model. C libraries wouldn't honor either of these. Also, consider a C function that returns a string (well, conceptually since it can't literally return a string). Either the caller has to pass a reference to a buffer that the function then fills, or the function has to allocate a properly sized buffer and return a reference to it. In the first case, that would force C# to use C's memory allocation rules (yes, C has rules, like you have to actually know the address and it can't be moved). In the second case, it would force the function and the app to agree on a memory management scheme. The chosen scheme would be guaranteed to be more difficult to use than the C# native scheme.
Also, C# isn't VB with curly braces. VB.Net is C# without curly braces. There is an important distinction. I have been around as many VB6 programmers transitioned to VB.Net. It is always a difficult process because almost none of the techniques necessary to write good VB.Net code are known to VB6 programmers because the features are new to VB.Net.
Finally, quick to compile is only important for those developing in Visual Studio. VS gives a lot of help and does a lot of reflection on the current code to give very specific help. VB.Net essentially incrementally recompiles the application every time you hit enter and in C# it is important to recompile often to keep intellisense up to date.
...to retrive the royalties I had earned...
Exactly what did you do to earn those dollars from the performance in Poland? Had they not played the music, would you have more free time to be with your family or to produce more music? Don't get me wrong, I'm for the fair compensation of artists. However, I believe that society should choose to provide incentives for artists to continue producing works of art. This is a willfull decision to give people a means to live (money) even though they don't produce anything that is physically valuable to society. It is a gift. You seem to believe that that money was rightfully owed to you and copyright law only serves to clarify that fact. The right to be free is natural, the right to be payed for music is not.
The public tide is turning. If you guys don't act a bit more gracious and keep letting these ruthless organizations do your dirty work, the people of the world may decide you are not worth the investment and go back to the old "patron of the arts" model where you get to be some rich guy's live-in artist.
I do some maintenance development. It takes me ten times as long to fix, test, and deploy an application than it does to fix the data corruption that results from the crash that the bug causes. However, by our metrics, one hundred data fixes per month is guaranteed to keep me under my SLA no matter how many other problem I solve slowly. If I ever choose to fix the issue, my SLA compliance will go into the toilet both because fixing it takes longer than the SLA and because I no longer get to log easy fixes. Some organizations fix the first problem by allowing fixes under a process with a different SLA, but no one can fix the second problem. I simply don't want this problem fixed ever.
If I were doing a good job, the problems that come up should be all be first-timers. Any issue should be root-caused and fixed before it becomes recurring. This implies that a healthy organization will have longer ticket close times than a broken organization. Anybody who's problem resolution times are going down has given up on fixing the underlying cause.
Actual example -- my company is now putting in password reset self-service. This is a huge win for the whole company (except for the security guys, they lost that argument). However, this is likely to increase the average ticket close time for level 1.
These software developers killed six people with a series of software bugs and general poor software development practices:
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
No one was personally held accountable.
http://www.channelinsider.com/c/a/Solution-Builder/We-Did-Nothing-Wrong-Why-Software-Quality-Matters/
21 people died due to a software error. The doctors that administered the doses were indicted for murder (I don't know the outcome), the software vendor was sued, but the developers were not personally held accountable. This one is interesting, because if the software had been built by an engineering firm and they had an licensed Professional Engineer stamp the design, he would have been held accountable.
More specifically, an Engineer is someone who can claim that a system won't kill people and can legally transfer the responsibility for the lives of the users from the construction company to himself. What we don't have in the software industry is the accountability that forces Engineers to be rigorous. Sure, we software developers can claim that we use rigorous processes, but every time something doesn't work, we shrug it off and get to work on the fix. If a real Engineer screws up big just once, he loses his license and/or goes to jail.
What makes licensed Professional Engineers so mad about the computer industry's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life. Don't think of an Engineer as someone who is good at any specific thing, think about them as a gatekeeper of the use of technology in public places.
Or hack the authentication system so that it thinks you already went through all that stuff when all you did was forge an authentication proof. Their system is very resistant to some types of attacks, like password guessing. But, it is no stronger than a normal username and password against most attacks on the system itself. SrongWebmail.com's biggest mistake was thinking that they knew of all of their weaknesses.
You're a moron. Torque is only a useful measurement if you fix all of the other variables. Horsepower is always a useful measurement.
Example: I can make an cheap Chinese corless drill make 1000 ft-lbs of torque simply by adding a reducing gear. 1000 ft-lbs of torque is only really meaningful if I first give the rpm at which that torque needs to be made. On the other hand, that Chinese drill is never going to make 1HP. Think of HP as the ability to create torque.
Oh.... I agree that 0-60 in 4 seconds is nothing to write home about. My streetbike does 0-60 in about 2.3 seconds. Gotta love 199.1 HP in a 400 pound package.
Engines are designed to approach detonation at peak load. At part-throttle cruising, where an engine will be 99% of the time in a fuel economy study, throttle vacuum and low thermodynamic loads will keep the engine far from the detonation point. No matter how low octane fuel you put in a vehicle, the knock sensor will not go off at cruise. So, any effect that ignition timing may have on the engine will not be a factor in fuel economy unless you drive it like a race car.
Small turbo engines are an exception, as they can keep cylinder pressure up even at low load. But all normally aspirated engines will not get better mileage from an octane level higher than they were designed for. Today's aluminum blocks and pistons can easily transfer all of the heat from the center of the piston at part throttle. Heck, if flame temperature was the primary issue, that could easily be taken care of with a colder spark plug.
BTW, using 100% ethanol to fuel our cars will not prevent us from importing oil for critical industries (other than the auto industry). So, no matter what we do, we will still have the same military expeditures to secure our access to oil. That's why it isn't factored into ethanol savings -- because we simply cannot live the way we do without imported oil.
Also, buying oil with US dollars, then taking those dollars back for CDOs backed by mortgages that were overvalued, was our way of buying oil with fake money. We pay real money for ethanol. Those dictators have oil, someone will always give them money for it.
Any study that shows high octane fuel giving better fuel consumption should be suspect immediately. Octane does not equate to energy content. High octane gas is also not "better gas". It does not reduce wear or carbon buildup. Higher octane fuel is simply more resistant to pre-detonation than lower octane fuel. Most of the time, it takes additives to make a fuel more detonation resistant and the additives reduce fuel efficiency.
Yea, but you also get the overhead of two schedulers (the host and the guest) and two systems moving thread context from core to core, which is an expensive operation. Most VMware systems are pretty heavily oversubsubscribed in terms of cores. Its not uncommon to have 60 guests on a 16 core host. If all 60 guests have 4 virtual CPUs, you do get the advantage that one guest can expand out to consume about a quarter of the total host CPU power, but you also have the cost of guest SMP switching even though you are using an average of 0.25 cores per guest.
He didn't say to use a single vCPU for a non-SMP aware app, he said to use a single vCPU for all application loads. For SMP aware apps, adding another virtual CPU is a scaling option. If you have non-SMP aware apps, then you need to find another solution, like migrate to a host with faster cores.
It makes sense. If you have 32 workloads and 16 cores, don't add the overhead of making 64 virtual vCPUs, 32 will use the host resources more efficiently as long as one app doesn't need the power of more than one core. If it does, give it to the guest only when it needs it.
I would only expect to make more because even at a higher price, I'd be among the low bidders. Mowing a difficult lawn isn't more expensive because it is more work, it is more expensive because no one will provide the service for a lower cost. This example doesn't illustrate the difference, but consider this--
If someone invented a lawn mowing system that was very cheap and could turn lawn mowing into a nearly effortless and fast operation, the work=money theory would lead to the conclusion that a professional lawn servicer would simply do more lawns in a day and make the same money for the same effort. In reality, lawn mowing would become an almost non-sellable service as most people would do it themselves. For the few professionals that remain, the price per unit of effort would go down because the potentially qualified pool of labor would be larger.
The book publishing industry has been like this for years, and with eBooks, is getting more so like this. Publishing was never very expensive, creation is. The payment isn't for the cost of creation, it is literally ransom for reading the content. The system only works this way because no one can think of a better one, not because it is supposed to work this way.
I am not saying that copyright is bad or that books should be free. I am simply pointing out that an author isn't entitled to be paid for their work by units of effort. We, as a society, have chosen to value their effort and have contrived a very flakey system to encourage authors to write. I'm sure we can do better and we should take every opportunity to look at alternative systems.
If your time is worth nothing, that is fine, but most people's time is more valuable than that.
So, a product is worth the time and effort put into it?
If I mowed your lawn with tweezers, would it be worth more than if I did it with a lawnmower? If I wrote a book that was the alphabet repeated six million times, all typed by hand, would it be worth anything? The "time is money" math only works on the producing end. If I could make $4 for an effort that takes two hours, I probably wouldn't do it. It doesn't automatically mean that if something takes time then it is worth money.
The idea of letting an author make money from an original work is a specific interference in the normal process of the economy by the government to try to entice production of such works. It is not a natural right or an entitlement.