I was going to make the same comment about following too close, but I have to disagree on worst driver status.
That honour goes to the idiot who was backing up in the slow lane on a divided highway the other day in front of me. That's right, i saw the whites of his reverse lights as he weaved around trying to back his car up to get to the missed off-ramp. Not only was he in reverse on the road, but on a major highway, and not on the shoulder, and couldn't drive in a straight line in reverse anyway.
Yes, I speed-dialled the authorities as I avoided him.
We had to do this in my driver training. Throw the car in neutral, turn off the power, then turn it back on again with your foot over the brake in case something on the road requires your attention.
The car shuts off, and turns back on just fine without coming to a stop.
Not that its relevant in this case, but many people don't realize their GPS is tracking speed only in two dimensions and not taking into consideration any incline. The only time my GPS and speedometer are out of whack on my car are when I'm going up or down a hill, in which cases the GPS shows a slower speed than does my speedometer. The rest of the time however, my dash speedometer is actually a bit slower than the GPS (gotta watch those speeding tickets).
Many years ago I had set up a set of systems for a customer to be nice and secure yet functional until someone bought a Blackberry and the sync software wouldn't run without admin.
Even doing 'run as...' wouldn't do it, we had to give him administrative privileges on the local machine, and then everyone else who got one too.
You used a lot of words to simply say "passwords chosen by humans are typically easier to crack than randomly generated ones."
Explicitly encrypting the file with symmetric encryption doesn't make anything any easier than using public key encryption, its the choice of symmetric key that matters (since one is used in both cases).
Thanks for the inane and completely uninteresting reply. Creating an index file that cripples system performance is not actually that helpful though. Eventually the trade-off isn't one anymore and the system is too slow maintaining the index to be usable.
I had the same problem with Google Desktop. It was a great tool and worked well for a while, but eventually its little database file was immense and was dragging my system down with it.
To be fair I think the gp meant Linux exclusive, not native. But even then Firefox is a pretty bad choice, since its development has always had Linux in mind as well as other platforms.
If you benchmark some random 3D games between Linux and Windows there is no Linux slow-down. If you benchmark the responsiveness of a well written GUI environment on Linux vs Windows, there's no slow-down. In fact, I've only rarely run into a situation where Linux is slower than Windows in a GUI or otherwise. The primary reason I've come to realize is lazy programmers writing slow client software, and in some cases, horribly inefficient GUI toolkits (Gtk, I'm looking at you).
X11 isn't the bottleneck, and ever since a few tweaks were done for desktop users, the Linux kernel isn't either.
Evidently you couldn't read my complaint about original argument, but at least you acknowledged the fault in your logic this time: "Two drives identical would be running at 280MB/s on the same test, assuming the bus can keep up."
The whole point of this discussion is whether the bus can keep up. Making assumptions about that in a discussion on benchmarking is laughable. Please measure it before replying.
An irrelevant note I might add. All PGP/GPG encrypted data is symmetrically encrypted using a randomly generated key. It is only that resulting key that is then encrypted using the public key, for speed reasons.
The security of your data depends heavily on the random number source used for generating these session keys.
Ignoring your rant about power for a minute (i've had more than my fair share of USB power troubles), this is just pure silliness:
And it's not just 40% faster. One drive was 40% faster. I assume USB can scale to at least 2 devices, so that would make it 280% faster.
Assuming for a moment that a drive is 40% faster but was close to saturating the bus, a second drive wouldn't be any faster at all. No, i didn't run the numbers, but neither did you -- that assumption just makes no sense.
Except that Intel has everything to gain from USB over Firewire. USB has higher CPU overhead (they sell CPUs) and requires a controlling host (more CPUs sold).
Firewire can run between two low-powered devices, leaving Intel off the radar.
There are features Firewire has that still don't exist in either USB or eSATA. As a result, it will probably live on for quite some time in its niche markets because it does what its designed for very very well. Dedicated bandwidth with sideband control data and no need for a host controller.
Firewire never was the right way to hook up a mouse and keyboard, but for transferring video from a camcorder to an editor, its the best way.
You can think of it that way, but that's no different than saying "this material is so easy, you'll know it all in five minutes" with the same resulting curve.
Your comment on difficulty is not in fact the curve itself, but an outside force resulting in the curve. This "need" you cite does not exist in the math of the knowledge over time curve, the curve just expresses the data.
Almost everyone has muscle memory. The fact that you may never re-use that knowledge (because you're bound to a calculator or keyboard) is the problem, not that you won't learn doing it.
To be honest, my only problem with this entire scenario is the proof that the event was in fact less than 2.5 seconds long. I'm slightly curious how we can know this out of band, that is to say, from data other than that which we're already unsure of how to measure.
Every study I know of has said exactly that. The conversation on the cell phone is the problem, not the hands-on nature of the phone itself.
There is almost no difference in distraction between talking on the phone while driving hands-free and talking on a hand-held phone.
That said, I'd love to know if there's even any difference between those and talking to a passenger. While I've seen people hypothesize about it, I haven't seen any hard data. Personally, I'd suspect they're all pretty equal in their innate distraction level.
I have been known on a busy road with severe weather to tell my family to be quiet so I can concentrate better. To be honest though, driving doesn't require 100% of the concentration of most people, most of the time, and requiring that is to ignore reality.
The actual law passed prevents the use of hand-held entertainment or communication devices. Dash-mounted devices are not included. Non-entertainment and communication devices are not included.
This does not in fact prevent someone from doing their masquera while driving (which I've seen) or painting their nails (which I've also observed) or curling their hair (seen that too). Nor will it prevent or give special mention to people who fumble on the floor of the passenger side for the CD they dropped, while driving at high speeds and weaving around due to a total lack of attention on the road.
I'd much rather let people dial their phones with their hands.
They require you to relinquish your encryption keys for a reason.
There are similar dilemmas in law enforcement in North America -- if you won't roll down your window for the police when they pull you over for example, and they force their way into your vehicle, they've just committed (in most cases) an illegal search and everything else becomes fruit of the poison tree*.
Police procedure combined with human rights can in fact hinder investigation of some crimes, but some of us would argue that the rights and liberties are more important.
Slashdot Mirror
I was going to make the same comment about following too close, but I have to disagree on worst driver status.
That honour goes to the idiot who was backing up in the slow lane on a divided highway the other day in front of me. That's right, i saw the whites of his reverse lights as he weaved around trying to back his car up to get to the missed off-ramp. Not only was he in reverse on the road, but on a major highway, and not on the shoulder, and couldn't drive in a straight line in reverse anyway.
Yes, I speed-dialled the authorities as I avoided him.
We had to do this in my driver training. Throw the car in neutral, turn off the power, then turn it back on again with your foot over the brake in case something on the road requires your attention.
The car shuts off, and turns back on just fine without coming to a stop.
Not that its relevant in this case, but many people don't realize their GPS is tracking speed only in two dimensions and not taking into consideration any incline. The only time my GPS and speedometer are out of whack on my car are when I'm going up or down a hill, in which cases the GPS shows a slower speed than does my speedometer. The rest of the time however, my dash speedometer is actually a bit slower than the GPS (gotta watch those speeding tickets).
Many years ago I had set up a set of systems for a customer to be nice and secure yet functional until someone bought a Blackberry and the sync software wouldn't run without admin.
Even doing 'run as ...' wouldn't do it, we had to give him administrative privileges on the local machine, and then everyone else who got one too.
You non-haters need to think more.
You used a lot of words to simply say "passwords chosen by humans are typically easier to crack than randomly generated ones."
Explicitly encrypting the file with symmetric encryption doesn't make anything any easier than using public key encryption, its the choice of symmetric key that matters (since one is used in both cases).
Thanks for the inane and completely uninteresting reply. Creating an index file that cripples system performance is not actually that helpful though. Eventually the trade-off isn't one anymore and the system is too slow maintaining the index to be usable.
I've not had a problem with any of those areas in the modern era of Linux use. Have you?
I run 3D games on my system at high frame rates while it simultaneously downloads with Vuze and serves music and videos to the PS3 for my wife.
'sar' shows me that there's a lot of task switching going on, and a lot of activity, but it never seems to have any effect on productivity.
Windows has the GDI and DirectX, neither of which are remotely comparable to the X window system.
I had the same problem with Google Desktop. It was a great tool and worked well for a while, but eventually its little database file was immense and was dragging my system down with it.
To be fair I think the gp meant Linux exclusive, not native. But even then Firefox is a pretty bad choice, since its development has always had Linux in mind as well as other platforms.
If you benchmark some random 3D games between Linux and Windows there is no Linux slow-down. If you benchmark the responsiveness of a well written GUI environment on Linux vs Windows, there's no slow-down. In fact, I've only rarely run into a situation where Linux is slower than Windows in a GUI or otherwise. The primary reason I've come to realize is lazy programmers writing slow client software, and in some cases, horribly inefficient GUI toolkits (Gtk, I'm looking at you).
X11 isn't the bottleneck, and ever since a few tweaks were done for desktop users, the Linux kernel isn't either.
Evidently you couldn't read my complaint about original argument, but at least you acknowledged the fault in your logic this time: "Two drives identical would be running at 280MB/s on the same test, assuming the bus can keep up."
The whole point of this discussion is whether the bus can keep up. Making assumptions about that in a discussion on benchmarking is laughable. Please measure it before replying.
An irrelevant note I might add. All PGP/GPG encrypted data is symmetrically encrypted using a randomly generated key. It is only that resulting key that is then encrypted using the public key, for speed reasons.
The security of your data depends heavily on the random number source used for generating these session keys.
Luckily for the project, both you and the GP are the rare members of society who, like myself, think of deviant ways to hack the system.
Most people are sheep.
Ignoring your rant about power for a minute (i've had more than my fair share of USB power troubles), this is just pure silliness:
Assuming for a moment that a drive is 40% faster but was close to saturating the bus, a second drive wouldn't be any faster at all. No, i didn't run the numbers, but neither did you -- that assumption just makes no sense.
Except that Intel has everything to gain from USB over Firewire. USB has higher CPU overhead (they sell CPUs) and requires a controlling host (more CPUs sold).
Firewire can run between two low-powered devices, leaving Intel off the radar.
There are features Firewire has that still don't exist in either USB or eSATA. As a result, it will probably live on for quite some time in its niche markets because it does what its designed for very very well. Dedicated bandwidth with sideband control data and no need for a host controller.
Firewire never was the right way to hook up a mouse and keyboard, but for transferring video from a camcorder to an editor, its the best way.
You can think of it that way, but that's no different than saying "this material is so easy, you'll know it all in five minutes" with the same resulting curve.
Your comment on difficulty is not in fact the curve itself, but an outside force resulting in the curve. This "need" you cite does not exist in the math of the knowledge over time curve, the curve just expresses the data.
But that makes the article's subject redundant since the pay-for service is Tomtom.
Almost everyone has muscle memory. The fact that you may never re-use that knowledge (because you're bound to a calculator or keyboard) is the problem, not that you won't learn doing it.
Just look at a curve representing knowledge over time.
If the curve is steep, you're learning a lot over a little time.
The less steep the curve, the less you're learning for a given amount of time, therefore the harder the material in question is.
Nobody has to be right for another to be wrong.
To be honest, my only problem with this entire scenario is the proof that the event was in fact less than 2.5 seconds long. I'm slightly curious how we can know this out of band, that is to say, from data other than that which we're already unsure of how to measure.
Every study I know of has said exactly that. The conversation on the cell phone is the problem, not the hands-on nature of the phone itself.
There is almost no difference in distraction between talking on the phone while driving hands-free and talking on a hand-held phone.
That said, I'd love to know if there's even any difference between those and talking to a passenger. While I've seen people hypothesize about it, I haven't seen any hard data. Personally, I'd suspect they're all pretty equal in their innate distraction level.
I have been known on a busy road with severe weather to tell my family to be quiet so I can concentrate better. To be honest though, driving doesn't require 100% of the concentration of most people, most of the time, and requiring that is to ignore reality.
The actual law passed prevents the use of hand-held entertainment or communication devices. Dash-mounted devices are not included. Non-entertainment and communication devices are not included.
This does not in fact prevent someone from doing their masquera while driving (which I've seen) or painting their nails (which I've also observed) or curling their hair (seen that too). Nor will it prevent or give special mention to people who fumble on the floor of the passenger side for the CD they dropped, while driving at high speeds and weaving around due to a total lack of attention on the road.
I'd much rather let people dial their phones with their hands.
They require you to relinquish your encryption keys for a reason.
There are similar dilemmas in law enforcement in North America -- if you won't roll down your window for the police when they pull you over for example, and they force their way into your vehicle, they've just committed (in most cases) an illegal search and everything else becomes fruit of the poison tree*.
Police procedure combined with human rights can in fact hinder investigation of some crimes, but some of us would argue that the rights and liberties are more important.
*IANAL