The way I learned about volatile is that it is to be used for memory that is modified out of the scope in which it is used.
What about memory that isn't supposed to be modified out of the scope in which it is used? That's the point. bugs/vulnerabilities that lead to memory that is NOT SUPPOSED to be volatile.
But as soon as you open the can of worms and say, "well... if there's a bug, then maybe it will be modified out of scope somehow... " and then ALL memory is considered volatile.
If you have that understanding of volatile, then it fits perfectly with its use to prevent a memset() from being removed.
Why does it fit? The memory you are updating with memset is non volatile. Like any other 'normal' variable or buffer it is not supposed to be read or modified out of scope.
You have flipped the definition upside down. And as soon as you do that you have to consider the possibility that any other memory in your system that isn't supposed to be modified or read out of scope might, in actuality, be equally 'volatile'.
I read the argument about math not being patentable, but I don't really understand why.
Facts aren't patentable. Everything in math is either a fact (or unprovable axiom which is taken as fact) or is a logical consequence of those facts, and are in turn facts in their own right.
All mathematical methods can be restated as statements of fact about mathematical relationships.
For example suppose I were to attempt to patent a method for computing the length of the hypotenuse of a right triangle. You take side a and square it, and take side b and square it, and then take the positive square root of that to get the length of the hypotenuse... except that "method" is just a particular way of stating the mathematical fact that
a^2 + b^2 = c^2
A fact. That is not patentable.
And all mathematical "methods" have this same characteristic.
When you get to information theory, encryption, compression etc... its just vastly more complicated, but at the end of the day its still just the expression of mathematical facts.
Similarly software is just a specialized notation for manipulating numbers; we associate it with 'computers' but it can be abstracted as pure math, its just set theory, mapping functions, and so forth, and it can be expressed in purely mathematical form.
A new data compression algorithm that is truly novel seems like it should deserve some protection so that the inventor can get rewarded for her work. No?
There's the rub. On the one hand, yes, we want to reward people for hard work, and DISCOVERING the mathematical relationships that allow for the expression of a new compression is very difficult, but on the other hand its not an invention, its still just a factual mathematical relationship and facts are not patentable.
She is not an inventor, she's a mathematician. She solved a math problem. That's not to say its not hugely difficult or that she wasn't creative. But its still not an invention.
Lots of people solve hugely difficult problems -- that isn't the criteria by which we determine whether they are patentable. No more than you can't solve a difficult sudoku and patent the solution... regardless of how hard the sudoku was.
Except that "volatile" means that the memory might be accessed through methods other than the program,
Exactly right.
The trouble is in the case of a bug or vulnerability, even non-volatile memory might be accessed/updated when its not supposed to be. And any sanity checks or range changes or bounds checks you might write to try and close the potential holes require the non-volatile memory be marked volatile to prevent the compiler optimizing out the checks.
See my other reply for a contrived example of what I'm trying to explain.
I'm not sure you typed that in right, or maybe you don't understand what volatile means or when to use it.
No I typed it in right. That's the point. To guard against security flaws, you need to specify volatile in situations where you explicitly expect it not to be volatile; so that any sanity checks you put in place don't get optimized out as redundant/dead code.
For security you effectively have to assume all memory is volatile, and that it might be changed when it shouldn't be.
For a contrived example,
static buffer static int x
[...]
somefunction() {
x = 7
loop
int y = x;
do somestuff(buffer)// this doesn't adjust y or x
sanity check: if y != x call error("WTF somethings horribly wrong! abort!")
end loop.... }
Neither y nor myvariable are volatile, they aren't supposed to be modified except as assigned above. So why should I mark anything volatile?
Because during somestuff() the 'buffer' got overrun and it wasn't detected, so x got overwritten during the loop. I had a sanity check, but the compiler optimized it out because it thought nothing updated x or y.
So now I have to mark x volatile to restore the security check? To tell the compiler, that even though nothing should have altered x or y, I need it to run the sanity check to make sure of that.
(Yes, yes, the real problem is in somestuff() where the buffer got overrun in the first place, but that's someone else's code or whatever.)
I have to mark x volatile when its NOT supposed to change externally. Its only 'volatile' because of a 'bug'. Its not volatile by design. If I don't mark it volatile then the sanity check gets optimized away, and the software is vulnerable.
The trouble is the circumstances of x are the same as ANY other memory in my system, so now it all has to be marked volatile, to ensure my sanity checks evaluate. That's not good.
Any code removal by the compiler can be prevented by correctly coding the code with volatile (in C) or its equivalent.
Knowing that the code will be removed by the compiler is paramount to using the volatile keyword.
That requires knowing a lot more about what the compiler is going to do then one should presume. The developer should not have to have foreknowledge of what compiler optimizations someone might enable in the future, especially as those optimizations might not even be known in the present.
The normal use case for 'volatile' is to tell the compiler that you know and expect the memory will be modified externally; and beyond that you don't really need to know exactly what the compiler does. As the developer reasonably knows that the memory is supposed to be modified externally, it is not unreasonable that he mark it as such.
Most security related vulnerabilities arising from compiler optimization tend to revolve around the idea that you are defending against memory being modified externally that should not normally be modified or read from externally. But that is the DEFAULT assumption for all memory.
If you do not expect the memory to be written to or read from, you don't mark it volatile.
So now you are saying, well, if you REALLY don't expect the memory to written to or read from externally, then you should mark it volatile.
So... that has us marking everything volatile that we know will be modified or read from externally, and also everything that we know should NOT be modified or read from externally... so clearly we should mark everything volatile all the time... because pretty much all memory is either "supposed to be read and written to externally" or "not supposed to be read and written to externally" and the only situation where its safe not to use volatile then is when you don't care if its read or written to externally because you KNOW that it can't cause a bug or expose a vulnerability.
I can't offhand think of many situations where I could say with any degree of certainty that if something read or wrote to memory externally that it wouldn't matter, and it would rarely be the best use of my time to try an establish it... so really... mark everything volatile all the time.
Right now gasoline and diesel is what powers well over 99% of the vehicles on the road
I'm not suggesting we repeal the existing gas tax. I agree with your points about Ferrari's being needlessly fuel inefficient, and so they should pay more than civics or electrics, and I agree that using the tax to motivate people towards fuel efficiency and electrics is a good idea. I just think it shouldn't be where we look to go forwards.
I think electric vehicles are the future [...]
Right. So lets show some foresight. Lets have the law in place as the future arrives instead of being hopelessly behind for once.:)
The fuel tax isn't going away, so they will still pay more. It will still be a tax advantage to drive an electric, etc. But we'll have a sensible tax framework in place to maintain infrastructure as the fleet transitions to electric... and we'll still fine if Mr. Fusion pops in or if people start avoiding the electrical taxes with solar chargers.
Who is going to read the odometer and how often?
Annually, when you renew your insurance. That' real time enough. It doesn't require big brother, they are equipped to take your money, and all the bureaucracy necessary is already in place.
Around here, (they don't do it any more and I'm not sure why to be honest) but they used to even be required to physically verify the VIN number when you renewed your insurance, and perform a very cursory inspection (indicator lights, headlights, tire tread etc).
No. They are trying to measure the growth of the problem. So its not important which one is absolutely faster, but which one takes relatively more time as the problem becomes more difficult.
The conventional computer should take exponentially longer as the problem becomes mroe difficult. The quantum one should not.
In this test, both took exponentially longer. So either the d-wave doesn't work, or as the manufacturer has claimed, the problems were not setup to demonstrate the class of problems where the d-wave will show better performance relative to problem complexity growth than a conventional computer.
Seems odd to me though that they can't provide easily verified sample problem spaces where their device works better than a conventional PC as the problem gets 'bigger'.
I thought about mentioning a tire tax, but i think odometer / mileage based taxes are better.
The problem with tire taxes are that, as you observed, they'd DRAMATICALLY increase the price of tires.
Tires are crucial safety equipment, and putting a consumption tax on them will just motivate all kinds of STUPID.
From black market tire changes in Mexico or Canada, and people avoiding replacing tires until they were well past unsafe, people running (and manufacturers pushing) harder tires with poorer braking characteristics simply to market to people looking to avoid or minimize the tax, etc.
And what good is that if the vehicle rarely gets driven?
Since I said it should be linked to mileage x weight, a vehicle that doesn't move much isn't going to pay much no matter how much it weighs.
There are environmental benefits to taxing those who needlessly consume more of a resource than necessary.
And if we all get electrics, the guy with a Ferrari can pay for all the roads by himself right? I agree with you that Ferrari's paying a larger proportion than Civics is still fair... call it a 'luxury tax' on driving a needlessly powerful car... but a Model S? A 4600 lb luxury car gets its road use subsidized by the people in old civics? Sorry that just doesn't fly as fair.
Gas usage is about as good as it gets
Really, in a world where a growing percentage of cars don't use any at all?
Bigger cars generally consume more gas and cars that drive more consume more gas
Unless they don't. See Tesla Model S, above. Ginormous car, zero gas.
Perfect is the enemy of good here.
Odometer readings and vehicle weight is a much better proxy for road usage than gasoline is. Its not perfect either (QQ... I had a track day and racked up 400 miles on a private road... QQ... I went to mexico on vacation and racked up 1600 miles on roads in another country... QQ) but its still far better than gasoline.
a. Gas is much too cheap in the US. b. We need a lot of infrastructure work.
True on all points, but electrics should contribute as much as gasoline powered cars from Honda to Ferrari.
At this stage the tax should be on the odometer; read and applied when you renew your insurance.
And if its going to scale to anything it should be correlated to vehicle weight.
A Ferrari may drink 4x as much gas as a Honda Civic, but it causes the same wear on the infrastructure. The 4,600 lb Tesla does more wear and tear than a 2700 lb Ferrari 458 or 2800 lb Honda Civic coupe.
Never mind what the dump trucks and rigs do to the roads -- although one can argue that the regular motorist should 'subsidize' thier impact. In any case passing direct costs to heavy vehicles would just make those MUCH more expensive to operate which would just translate in higher transportation costs and higher construction costs that get passed back to us anyway...
I was going to reply to try and explain what I meant, but I started by looking up the movie and found it was released in 68, so by calling it a 70s movie I've inadvertently credited it with being ahead of its time.
I guess it was a bad 60s movie.:)
-sigh-
But I still maintain it was bad movie, it doesn't follow the novel well at all, and they crowbar in scenes that just don't fit, and it all seems very cliche... its like a director read the script and said its too boring, add a motorcycle ride, and some sex scenes.
All that presupposes you do this and the hacker never gets in.
But
a) once the hacker is in they can do all that, they can change the billing info, they can change the ACLs to lock you out too, etc.
b) Its clearly more more sophisticated to both prevent a hacker getting in and knocking them out once they are, making the cloud riskier than more traditional methods of hosting.
What are you using as the disk? How much of an impact does it make, and in what circumstances? Have you ever benchmarked it vs having it on the OS drive, I assumed SSD there as well?
I've never understood this term. It makes no sense as an informative expression
\shrug -- the 'internet' is traditionally a network of computers and the network gear to connect them. The 'internet of things' is connecting everything that isn't really recognized as a 'computer' to the internet.
Sure strictly speaking, any 'thing' that is capable of being connected to the internet rises to become a 'computer' in some sense, but people still retain a cognitive sense that some things are computers, and other things which might technically be computers are still not normally counted as computers.
Those are the 'things' on the 'internet of things'.
Not the best term for it perhaps... but not the worst.
I don't think their problem is necessarily because it was "on the cloud"
No. The cloud was a key part of the problem. They had as much access and control over the system as the hacker did with no physical fall back.
A VM farm on an onsite rack or even a colo rack? You knock out the hacker by unplugging it from the router to the internet, and then audit and reset security to your hearts content.
Today's under 25 crowd thinks failure to have a facebook account is automatically suspicious
Maybe its already passing its time. You said 'under 25 crowd' but I suspect that it doesn't go much younger than 18 or 20.
My kids are heading into middle school and high school and neither want anything to with facebook (which I admit I've encouraged). Some of their friends do have accounts, others don't, and nobody seems to think its really cool or a big deal. For those that have them its becoming where they go to see the pictures of grandma's birthday that their mom posted. Because what teen doesn't want to see pictures of grandma turning 82.
The 20-30 crowd still seems a lot more facebook engaged though... for now at least.
Some will call me a troll, but as a gamer I'm no longer interested in 4K video since I know Occulus Rift (and competing VR set) are coming.
As a gamer I'm not really concerned about 4k either. I'm much more interested better support for 3-view type setups. And 4k 3-view is just all the gamer problems of 4k times 3:)
Oculus... I'm not sold on it. I see it as niche at best. Very cool in that niche though.
I would like to see head tracking go mainstream though.
Most car enthusiasts get a manual in a sports car for control, not "engagement"
That was true when a car enthusiast could shift better than an automatic system. That's no longer the case, as you mention with PDK, and your observation that current supercars are dispensing with manuals altogether.
These days, people who want the manual want it because they just enjoy the experience of shifting manually, and being more "engaged" with the engine management element of driving, because they enjoy that aspect of driving.
Electrics take it to the next level though, and eliminate the entire engine management aspect completely, and for me that robs the driver of half the experience of driving.
It replaces it with a pretty fantastic ride, and I can understand why you prefer it.
As for noise, that's just baseball cards in the spokes
Sure some cars did noise for noise sake, and I never cared for that, but the engine noise was a crucial, perhaps even the primary, engine status communication channel from car to driver.
Give me instant torque all the time and great handling. That's the real fun.
It guess its fun in its own right, sure. But its a different kind of fun.
and find the low speed torque, and the ability to concentrate on just speed and driving to be way more fun
How much concentration does it take to just push an accelerator and wait 10 seconds to reach 100kmh?:p
I kid, I kid.
Anyhow, I already conceded that electrics can deliver the same performance these days, or even better.
than a loud, dangerous, and inelegant ICE.
The noise is just part of the fun. I'm not into those 'exhaust systems' that just try to make noise, but I do like the sound of a properly tuned engine. And I've no idea what you are on about with respect to dangerous or inelegant. A Porsche engine, for example, is an engineering work of art in my opinion. (Yes, yours obviously differs.)
And yeah, as a daily commuter in traffic that has a tough time cracking 30kmh with frequent stops, I prefer driving an automatic, and your Leaf would probably be great.
But then, I don't really even consider a rush-hour commute to be "driving". Its not something I"d look forward to in any car. Except maybe driverless, so I could nap or read a book or something.
The lack of gear switching is exactly what makes it so mind-blowingly amazing.
Not only do I *enjoy* the little surges and plateaus that go with changing gears I *enjoy* being an integral part of making them happen.
I don't disagree with you about the Tesla 'wow' factor; it is an amazing car in tech, looks, and performance. I just don't really enjoy driving it as much as a manual. Just as I don't enjoy automatics or even tiptronics as much.
But take most of the fun out of driving fast. No engine, no rpm, no manual transmission.
Its like being given a steak dinner in pre-chewed form. Its all there, but its still ruined.:)
When I bought my current sports car I shopped for the manual 6 speed transmission, not because I imagine I can shift better than the computer in the tiptronic version. but because just its so much more engaging and in turn more fun to drive the manual.
Electrics are rapidly reaching the point where they deliver all the performance of a real sports car, and beyond, but I've still got zero interest in one. (Although I'd be fine with one as a commuter car.)
Maybe I'm just being sentimental.:)
What's not to like (except charging times)?
Charging time actually another item that makes them fairly useless as a track day car. I can (and must) refill the tank in my car a couple times on a good track day (including a fill up and the end of the day to get me back home). A fill up takes all of 5 minutes.
Re:The new Firaxis title was surprisingly good....
on
OpenXcom 1.0 Released
·
· Score: 1
If a game restricts the inventory system, skill trees etc, I'd say it has less strategy options than the original, reducing it to merely coin tossing.
That's absurd. Is Chess not a strategy game given you only get 16 fixed pieces to start with, in fixed starting positions, with fixed capabilities? Or Go, with its even simpler rules?
There are lots of definite right and wrong choices to make in xcom, and you still need to plan, and to have contingency plans, and escape plans, etc within a mission. I do agree the longer term strategy is a bit watered down relative to the original in terms of base construction, planning, etc. But which nations you support, and research decisions etc still dramatically affect outcomes.
And suddenly losing a soldier is not a "hard choice" because you plan for that.
Losing a solider is not a 'hard choice'. Choosing what to equip him with, and where to position him were the hard choices, made harder by having fewer backup soliders, and fewer backup supplies.
If you were told to flip a coin and figure out the result to win 1M dollars it would be a hard choice
No. That's not a hard choice at all. Pick a side, and flip the coin.
Choosing what equipment to outfit your xcom eu team is a harder choice than it was in xcom ufo because in xcom ufo, I could have piles of extra stuff. So it didn't matter as much if I put the wrong guy in the wrong place, or destroyed cover i didn't need to destroy because i had all the rockets and grenades i needed. You had to think harder about what you were likely to need, and when to use it when you did, because you couldn't brings lots of extra stuff.
It did suck Doom 3 having a soldier not being able to use a weapon and a flashlight at the same time. [...] In Doom 3 soldiers didn't know about duct tape
In the Doom 3 i played I had an entire arsenal of weapons. Which one was my flashlight attached to? Or did I have 9 flashlights?
I'm also not sure how I moved around, supersoldier or not, carrying a chainsaw, a minigun, a bfg9000, grenades, 2 shot guns, pistols, plasma gun, and a rocket launcher with 100 rockets not to mention ammo for everything else? And even the rocket launcher and plasma guns wouldn't penetrate interior walls... or even most furniture...
It was a game.
It sucks having a soldier able to carry a rocket launcher plus main weapon and not more than a single grenade.
It really wasn't better have them carry a rocket launcher 5 rockets, plus main weapon plus 12 grenades, plus smoke grenades, plus...XYZ and just nuke the entire landscape on any map without civilians...
and in fireaxis Xcom soldiers don't know about belts.
Or air support, or armor support, or artillery, or drone scouts, or showing up with more than 6 people,... the local police department regularly has more officers involved in a speed trap, but I can't take more than 6 soldiers to defend against an alien invasion? No its not 'realistic'. Its a game. The object was to win with those limited resources, and it was balanced such that it could be done. You don't need more than half a dozen grenades... and you figure out a tactical solution that doesn't require more. People beat iron man... so clearly the right strategy works, unless you really argue they just happened to brute force it until they guess right on hundreds of coin flips??
With regards to the mods I would like to play, but they won't come out on iOS/Android devices, and my desktop machines aren't capable of running the game.
You do realize that a lot of the reasons the new xcom was so, shall we say, streamlined, was precisely to facilitate having the game on ios android and consoles. If they'd made the deeper game you wish it were... it would never have been out for ios at all. One of ~my~ complaints about the game was that they'd clearly "dumbed it down" for non-pc platform users.
Slashdot Mirror
The way I learned about volatile is that it is to be used for memory that is modified out of the scope in which it is used.
What about memory that isn't supposed to be modified out of the scope in which it is used? That's the point. bugs/vulnerabilities that lead to memory that is NOT SUPPOSED to be volatile.
But as soon as you open the can of worms and say, "well... if there's a bug, then maybe it will be modified out of scope somehow... " and then ALL memory is considered volatile.
If you have that understanding of volatile, then it fits perfectly with its use to prevent a memset() from being removed.
Why does it fit? The memory you are updating with memset is non volatile. Like any other 'normal' variable or buffer it is not supposed to be read or modified out of scope.
You have flipped the definition upside down. And as soon as you do that you have to consider the possibility that any other memory in your system that isn't supposed to be modified or read out of scope might, in actuality, be equally 'volatile'.
I read the argument about math not being patentable, but I don't really understand why.
Facts aren't patentable. Everything in math is either a fact (or unprovable axiom which is taken as fact) or is a logical consequence of those facts, and are in turn facts in their own right.
All mathematical methods can be restated as statements of fact about mathematical relationships.
For example suppose I were to attempt to patent a method for computing the length of the hypotenuse of a right triangle. You take side a and square it, and take side b and square it, and then take the positive square root of that to get the length of the hypotenuse... except that "method" is just a particular way of stating the mathematical fact that
a^2 + b^2 = c^2
A fact. That is not patentable.
And all mathematical "methods" have this same characteristic.
When you get to information theory, encryption, compression etc... its just vastly more complicated, but at the end of the day its still just the expression of mathematical facts.
Similarly software is just a specialized notation for manipulating numbers; we associate it with 'computers' but it can be abstracted as pure math, its just set theory, mapping functions, and so forth, and it can be expressed in purely mathematical form.
A new data compression algorithm that is truly novel seems like it should deserve some protection so that the inventor can get rewarded for her work. No?
There's the rub. On the one hand, yes, we want to reward people for hard work, and DISCOVERING the mathematical relationships that allow for the expression of a new compression is very difficult, but on the other hand its not an invention, its still just a factual mathematical relationship and facts are not patentable.
She is not an inventor, she's a mathematician. She solved a math problem. That's not to say its not hugely difficult or that she wasn't creative. But its still not an invention.
Lots of people solve hugely difficult problems -- that isn't the criteria by which we determine whether they are patentable. No more than you can't solve a difficult sudoku and patent the solution... regardless of how hard the sudoku was.
Except that "volatile" means that the memory might be accessed through methods other than the program,
Exactly right.
The trouble is in the case of a bug or vulnerability, even non-volatile memory might be accessed/updated when its not supposed to be. And any sanity checks or range changes or bounds checks you might write to try and close the potential holes require the non-volatile memory be marked volatile to prevent the compiler optimizing out the checks.
See my other reply for a contrived example of what I'm trying to explain.
I'm not sure you typed that in right, or maybe you don't understand what volatile means or when to use it.
No I typed it in right. That's the point. To guard against security flaws, you need to specify volatile in situations where you explicitly expect it not to be volatile; so that any sanity checks you put in place don't get optimized out as redundant/dead code.
For security you effectively have to assume all memory is volatile, and that it might be changed when it shouldn't be.
For a contrived example,
static buffer
static int x
[...]
somefunction() // this doesn't adjust y or x ....
{
x = 7
loop
int y = x;
do somestuff(buffer)
sanity check: if y != x call error("WTF somethings horribly wrong! abort!")
end loop
}
Neither y nor myvariable are volatile, they aren't supposed to be modified except as assigned above. So why should I mark anything volatile?
Because during somestuff() the 'buffer' got overrun and it wasn't detected, so x got overwritten during the loop. I had a sanity check, but the compiler optimized it out because it thought nothing updated x or y.
So now I have to mark x volatile to restore the security check? To tell the compiler, that even though nothing should have altered x or y, I need it to run the sanity check to make sure of that.
(Yes, yes, the real problem is in somestuff() where the buffer got overrun in the first place, but that's someone else's code or whatever.)
I have to mark x volatile when its NOT supposed to change externally. Its only 'volatile' because of a 'bug'. Its not volatile by design. If I don't mark it volatile then the sanity check gets optimized away, and the software is vulnerable.
The trouble is the circumstances of x are the same as ANY other memory in my system, so now it all has to be marked volatile, to ensure my sanity checks evaluate. That's not good.
Any code removal by the compiler can be prevented by correctly coding the code with volatile (in C) or its equivalent.
Knowing that the code will be removed by the compiler is paramount to using the volatile keyword.
That requires knowing a lot more about what the compiler is going to do then one should presume. The developer should not have to have foreknowledge of what compiler optimizations someone might enable in the future, especially as those optimizations might not even be known in the present.
The normal use case for 'volatile' is to tell the compiler that you know and expect the memory will be modified externally; and beyond that you don't really need to know exactly what the compiler does. As the developer reasonably knows that the memory is supposed to be modified externally, it is not unreasonable that he mark it as such.
Most security related vulnerabilities arising from compiler optimization tend to revolve around the idea that you are defending against memory being modified externally that should not normally be modified or read from externally. But that is the DEFAULT assumption for all memory.
If you do not expect the memory to be written to or read from, you don't mark it volatile.
So now you are saying, well, if you REALLY don't expect the memory to written to or read from externally, then you should mark it volatile.
So... that has us marking everything volatile that we know will be modified or read from externally, and also everything that we know should NOT be modified or read from externally... so clearly we should mark everything volatile all the time... because pretty much all memory is either "supposed to be read and written to externally" or "not supposed to be read and written to externally" and the only situation where its safe not to use volatile then is when you don't care if its read or written to externally because you KNOW that it can't cause a bug or expose a vulnerability.
I can't offhand think of many situations where I could say with any degree of certainty that if something read or wrote to memory externally that it wouldn't matter, and it would rarely be the best use of my time to try an establish it... so really... mark everything volatile all the time.
Clearly THAT isn't right.
Right now gasoline and diesel is what powers well over 99% of the vehicles on the road
I'm not suggesting we repeal the existing gas tax. I agree with your points about Ferrari's being needlessly fuel inefficient, and so they should pay more than civics or electrics, and I agree that using the tax to motivate people towards fuel efficiency and electrics is a good idea. I just think it shouldn't be where we look to go forwards.
I think electric vehicles are the future [...]
Right. So lets show some foresight. Lets have the law in place as the future arrives instead of being hopelessly behind for once. :)
The fuel tax isn't going away, so they will still pay more. It will still be a tax advantage to drive an electric, etc. But we'll have a sensible tax framework in place to maintain infrastructure as the fleet transitions to electric ... and we'll still fine if Mr. Fusion pops in or if people start avoiding the electrical taxes with solar chargers.
Who is going to read the odometer and how often?
Annually, when you renew your insurance. That' real time enough. It doesn't require big brother, they are equipped to take your money, and all the bureaucracy necessary is already in place.
Around here, (they don't do it any more and I'm not sure why to be honest) but they used to even be required to physically verify the VIN number when you renewed your insurance, and perform a very cursory inspection (indicator lights, headlights, tire tread etc).
No. They are trying to measure the growth of the problem. So its not important which one is absolutely faster, but which one takes relatively more time as the problem becomes more difficult.
The conventional computer should take exponentially longer as the problem becomes mroe difficult. The quantum one should not.
In this test, both took exponentially longer. So either the d-wave doesn't work, or as the manufacturer has claimed, the problems were not setup to demonstrate the class of problems where the d-wave will show better performance relative to problem complexity growth than a conventional computer.
Seems odd to me though that they can't provide easily verified sample problem spaces where their device works better than a conventional PC as the problem gets 'bigger'.
I thought about mentioning a tire tax, but i think odometer / mileage based taxes are better.
The problem with tire taxes are that, as you observed, they'd DRAMATICALLY increase the price of tires.
Tires are crucial safety equipment, and putting a consumption tax on them will just motivate all kinds of STUPID.
From black market tire changes in Mexico or Canada, and people avoiding replacing tires until they were well past unsafe, people running (and manufacturers pushing) harder tires with poorer braking characteristics simply to market to people looking to avoid or minimize the tax, etc.
And what good is that if the vehicle rarely gets driven?
Since I said it should be linked to mileage x weight, a vehicle that doesn't move much isn't going to pay much no matter how much it weighs.
There are environmental benefits to taxing those who needlessly consume more of a resource than necessary.
And if we all get electrics, the guy with a Ferrari can pay for all the roads by himself right? I agree with you that Ferrari's paying a larger proportion than Civics is still fair... call it a 'luxury tax' on driving a needlessly powerful car... but a Model S? A 4600 lb luxury car gets its road use subsidized by the people in old civics? Sorry that just doesn't fly as fair.
Gas usage is about as good as it gets
Really, in a world where a growing percentage of cars don't use any at all?
Bigger cars generally consume more gas and cars that drive more consume more gas
Unless they don't. See Tesla Model S, above. Ginormous car, zero gas.
Perfect is the enemy of good here.
Odometer readings and vehicle weight is a much better proxy for road usage than gasoline is. Its not perfect either (QQ... I had a track day and racked up 400 miles on a private road... QQ... I went to mexico on vacation and racked up 1600 miles on roads in another country... QQ) but its still far better than gasoline.
Good!
a. Gas is much too cheap in the US.
b. We need a lot of infrastructure work.
True on all points, but electrics should contribute as much as gasoline powered cars from Honda to Ferrari.
At this stage the tax should be on the odometer; read and applied when you renew your insurance.
And if its going to scale to anything it should be correlated to vehicle weight.
A Ferrari may drink 4x as much gas as a Honda Civic, but it causes the same wear on the infrastructure. The 4,600 lb Tesla does more wear and tear than a 2700 lb Ferrari 458 or 2800 lb Honda Civic coupe.
Never mind what the dump trucks and rigs do to the roads -- although one can argue that the regular motorist should 'subsidize' thier impact. In any case passing direct costs to heavy vehicles would just make those MUCH more expensive to operate which would just translate in higher transportation costs and higher construction costs that get passed back to us anyway...
I was going to reply to try and explain what I meant, but I started by looking up the movie and found it was released in 68, so by calling it a 70s movie I've inadvertently credited it with being ahead of its time.
I guess it was a bad 60s movie. :)
-sigh-
But I still maintain it was bad movie, it doesn't follow the novel well at all, and they crowbar in scenes that just don't fit, and it all seems very cliche... its like a director read the script and said its too boring, add a motorcycle ride, and some sex scenes.
Its perhaps not as newsworthy as the passing of Asimov, but its in the same general category.
Flowers for Algernon is easily one of the best and most influential short SF stories I've ever read.
The movie on the other hand, is pretty forgettable... its very much a 70s movie.
Thus, it wasn't the clouds fault....it was Code Spaces fault for not having the proper infrastructure.
Nobody is "blaming the cloud". The cloud is just inherently riskier.
You need to setup more sophisticated infrastructure up front to keep someone out, because you can't fall back to "pull the plug on them".
All that presupposes you do this and the hacker never gets in.
But
a) once the hacker is in they can do all that, they can change the billing info, they can change the ACLs to lock you out too, etc.
b) Its clearly more more sophisticated to both prevent a hacker getting in and knocking them out once they are, making the cloud riskier than more traditional methods of hosting.
re pagefile disk
I'm curious...
I assume windows 7 x64?
What are you using as the disk?
How much of an impact does it make, and in what circumstances?
Have you ever benchmarked it vs having it on the OS drive, I assumed SSD there as well?
I've never understood this term. It makes no sense as an informative expression
\shrug -- the 'internet' is traditionally a network of computers and the network gear to connect them. The 'internet of things' is connecting everything that isn't really recognized as a 'computer' to the internet.
Sure strictly speaking, any 'thing' that is capable of being connected to the internet rises to become a 'computer' in some sense, but people still retain a cognitive sense that some things are computers, and other things which might technically be computers are still not normally counted as computers.
Those are the 'things' on the 'internet of things'.
Not the best term for it perhaps... but not the worst.
I don't think their problem is necessarily because it was "on the cloud"
No. The cloud was a key part of the problem. They had as much access and control over the system as the hacker did with no physical fall back.
A VM farm on an onsite rack or even a colo rack? You knock out the hacker by unplugging it from the router to the internet, and then audit and reset security to your hearts content.
Today's under 25 crowd thinks failure to have a facebook account is automatically suspicious
Maybe its already passing its time. You said 'under 25 crowd' but I suspect that it doesn't go much younger than 18 or 20.
My kids are heading into middle school and high school and neither want anything to with facebook (which I admit I've encouraged). Some of their friends do have accounts, others don't, and nobody seems to think its really cool or a big deal. For those that have them its becoming where they go to see the pictures of grandma's birthday that their mom posted. Because what teen doesn't want to see pictures of grandma turning 82.
The 20-30 crowd still seems a lot more facebook engaged though... for now at least.
Some will call me a troll, but as a gamer I'm no longer interested in 4K video since I know Occulus Rift (and competing VR set) are coming.
As a gamer I'm not really concerned about 4k either. I'm much more interested better support for 3-view type setups. And 4k 3-view is just all the gamer problems of 4k times 3 :)
Oculus... I'm not sold on it. I see it as niche at best. Very cool in that niche though.
I would like to see head tracking go mainstream though.
It is time for the courts to learn that they do not have control outside their jurisdiction.
Your argument is valid and I agree with you.
On the other hand, who DOES have jurisdiction over googles global index then? Just Google, and no one else?
Is it then completely judgement and enforcement proof? Or to wax poetic is it above all laws of men, and beholden to no one?
Most car enthusiasts get a manual in a sports car for control, not "engagement"
That was true when a car enthusiast could shift better than an automatic system. That's no longer the case, as you mention with PDK, and your observation that current supercars are dispensing with manuals altogether.
These days, people who want the manual want it because they just enjoy the experience of shifting manually, and being more "engaged" with the engine management element of driving, because they enjoy that aspect of driving.
Electrics take it to the next level though, and eliminate the entire engine management aspect completely, and for me that robs the driver of half the experience of driving.
It replaces it with a pretty fantastic ride, and I can understand why you prefer it.
As for noise, that's just baseball cards in the spokes
Sure some cars did noise for noise sake, and I never cared for that, but the engine noise was a crucial, perhaps even the primary, engine status communication channel from car to driver.
Give me instant torque all the time and great handling. That's the real fun.
It guess its fun in its own right, sure. But its a different kind of fun.
Now I drive a Nissan Leaf,
But what does that have to do with driving? :p
and find the low speed torque, and the ability to concentrate on just speed and driving to be way more fun
How much concentration does it take to just push an accelerator and wait 10 seconds to reach 100kmh? :p
I kid, I kid.
Anyhow, I already conceded that electrics can deliver the same performance these days, or even better.
than a loud, dangerous, and inelegant ICE.
The noise is just part of the fun. I'm not into those 'exhaust systems' that just try to make noise, but I do like the sound of a properly tuned engine. And I've no idea what you are on about with respect to dangerous or inelegant. A Porsche engine, for example, is an engineering work of art in my opinion. (Yes, yours obviously differs.)
And yeah, as a daily commuter in traffic that has a tough time cracking 30kmh with frequent stops, I prefer driving an automatic, and your Leaf would probably be great.
But then, I don't really even consider a rush-hour commute to be "driving". Its not something I"d look forward to in any car. Except maybe driverless, so I could nap or read a book or something.
The lack of gear switching is exactly what makes it so mind-blowingly amazing.
Not only do I *enjoy* the little surges and plateaus that go with changing gears I *enjoy* being an integral part of making them happen.
I don't disagree with you about the Tesla 'wow' factor; it is an amazing car in tech, looks, and performance. I just don't really enjoy driving it as much as a manual. Just as I don't enjoy automatics or even tiptronics as much.
And electrics get you efficiency and torque.
But take most of the fun out of driving fast. No engine, no rpm, no manual transmission.
Its like being given a steak dinner in pre-chewed form. Its all there, but its still ruined. :)
When I bought my current sports car I shopped for the manual 6 speed transmission, not because I imagine I can shift better than the computer in the tiptronic version. but because just its so much more engaging and in turn more fun to drive the manual.
Electrics are rapidly reaching the point where they deliver all the performance of a real sports car, and beyond, but I've still got zero interest in one. (Although I'd be fine with one as a commuter car.)
Maybe I'm just being sentimental. :)
What's not to like (except charging times)?
Charging time actually another item that makes them fairly useless as a track day car. I can (and must) refill the tank in my car a couple times on a good track day (including a fill up and the end of the day to get me back home). A fill up takes all of 5 minutes.
If a game restricts the inventory system, skill trees etc, I'd say it has less strategy options than the original, reducing it to merely coin tossing.
That's absurd. Is Chess not a strategy game given you only get 16 fixed pieces to start with, in fixed starting positions, with fixed capabilities? Or Go, with its even simpler rules?
There are lots of definite right and wrong choices to make in xcom, and you still need to plan, and to have contingency plans, and escape plans, etc within a mission. I do agree the longer term strategy is a bit watered down relative to the original in terms of base construction, planning, etc. But which nations you support, and research decisions etc still dramatically affect outcomes.
And suddenly losing a soldier is not a "hard choice" because you plan for that.
Losing a solider is not a 'hard choice'. Choosing what to equip him with, and where to position him were the hard choices, made harder by having fewer backup soliders, and fewer backup supplies.
If you were told to flip a coin and figure out the result to win 1M dollars it would be a hard choice
No. That's not a hard choice at all. Pick a side, and flip the coin.
Choosing what equipment to outfit your xcom eu team is a harder choice than it was in xcom ufo because in xcom ufo, I could have piles of extra stuff. So it didn't matter as much if I put the wrong guy in the wrong place, or destroyed cover i didn't need to destroy because i had all the rockets and grenades i needed. You had to think harder about what you were likely to need, and when to use it when you did, because you couldn't brings lots of extra stuff.
It did suck Doom 3 having a soldier not being able to use a weapon and a flashlight at the same time. [...] In Doom 3 soldiers didn't know about duct tape
In the Doom 3 i played I had an entire arsenal of weapons. Which one was my flashlight attached to? Or did I have 9 flashlights?
I'm also not sure how I moved around, supersoldier or not, carrying a chainsaw, a minigun, a bfg9000, grenades, 2 shot guns, pistols, plasma gun, and a rocket launcher with 100 rockets not to mention ammo for everything else? And even the rocket launcher and plasma guns wouldn't penetrate interior walls... or even most furniture...
It was a game.
It sucks having a soldier able to carry a rocket launcher plus main weapon and not more than a single grenade.
It really wasn't better have them carry a rocket launcher 5 rockets, plus main weapon plus 12 grenades, plus smoke grenades, plus...XYZ and just nuke the entire landscape on any map without civilians...
and in fireaxis Xcom soldiers don't know about belts.
Or air support, or armor support, or artillery, or drone scouts, or showing up with more than 6 people, ... the local police department regularly has more officers involved in a speed trap, but I can't take more than 6 soldiers to defend against an alien invasion? No its not 'realistic'. Its a game. The object was to win with those limited resources, and it was balanced such that it could be done. You don't need more than half a dozen grenades... and you figure out a tactical solution that doesn't require more. People beat iron man... so clearly the right strategy works, unless you really argue they just happened to brute force it until they guess right on hundreds of coin flips??
With regards to the mods I would like to play, but they won't come out on iOS/Android devices, and my desktop machines aren't capable of running the game.
You do realize that a lot of the reasons the new xcom was so, shall we say, streamlined, was precisely to facilitate having the game on ios android and consoles. If they'd made the deeper game you wish it were... it would never have been out for ios at all. One of ~my~ complaints about the game was that they'd clearly "dumbed it down" for non-pc platform users.