I confused the two initially. The problem was not that I can't read, but that I wasn't aware that there were 2 implementations. I thought that maybe ssh had decided to call itself OpenSSH or something. I didn't think much of it. And there lies the problem. Now I know there are 2 it is a different matter.
This is clearly a problem and I think the OpenSSH project would not lose by a name change and would be doing a common courtesy to the original author who, after all, is just asking nicely.
Having read the entire article, but not listened to the realaudio (owing to no sound card at work), I seem to have missed the bit where he says what language it uses atm. Does anyone know offhand?
Please excuse me for never having looked at the Perl sources, or even downloading them. I got fed up with compiling it myself and nouse rpms.
This type of weapon poses an interesting dilema. It is as devastating as a nuclear device, which is good from a war-winning perspective, and it won't irradiate the planet in a nuclear winter which will wipe out the planet, which is very good.
However that last point is probably about the only thing that stopped MAD during the Cuban Missile crisis. Paradoxically, having our devastating weapons destroy the planet may be a good thing.
Several posters have voiced concern over Sun's potential use of a restrictive contract, however I doubt at this early stage that Sun would be in the position to use one.
As this is the first education use of the system it is only a pilot. It could turn out that the card keys are completely inappropriate for schoolchildren. The lack of campus expertise could mean that server failures take 3 days to fix, or that the server gets thrashed when timetables clash. The keyboards might break when a child thinks about a Cola and the monitors blow up at the first sign of a spit ball fight.
There's only so much you can test/think of in the lab. The real world is the only true testing ground and while Sun's system may turn out to be fantastic, they won't have much of a position until it's tried and tested.
All of these options would presumably require the web site to support the system. The chances are that for a significant period of time most would not. Or of course it might never take off and they never will.
This means that the user will still be sending credit card details by the old 'insecure' method for at least some purchases, or at least it will not be unusual for a single account to regularly use both methods. Also the old method is open to the simple attack of jotting down the details of the card having merely seen it.
Would it not make sense for a user to choose to only allow transactions on the account using the new secure method. Surely if this isn't possible, much of the security is made irrelevant.
Slashdot Mirror
I confused the two initially. The problem was not that I can't read, but that I wasn't aware that there were 2 implementations. I thought that maybe ssh had decided to call itself OpenSSH or something. I didn't think much of it. And there lies the problem. Now I know there are 2 it is a different matter. This is clearly a problem and I think the OpenSSH project would not lose by a name change and would be doing a common courtesy to the original author who, after all, is just asking nicely.
Please excuse me for never having looked at the Perl sources, or even downloading them. I got fed up with compiling it myself and nouse rpms.
However that last point is probably about the only thing that stopped MAD during the Cuban Missile crisis. Paradoxically, having our devastating weapons destroy the planet may be a good thing.
As this is the first education use of the system it is only a pilot. It could turn out that the card keys are completely inappropriate for schoolchildren. The lack of campus expertise could mean that server failures take 3 days to fix, or that the server gets thrashed when timetables clash. The keyboards might break when a child thinks about a Cola and the monitors blow up at the first sign of a spit ball fight.
There's only so much you can test/think of in the lab. The real world is the only true testing ground and while Sun's system may turn out to be fantastic, they won't have much of a position until it's tried and tested.
This means that the user will still be sending credit card details by the old 'insecure' method for at least some purchases, or at least it will not be unusual for a single account to regularly use both methods. Also the old method is open to the simple attack of jotting down the details of the card having merely seen it.
Would it not make sense for a user to choose to only allow transactions on the account using the new secure method. Surely if this isn't possible, much of the security is made irrelevant.
How does it perform compared to the Windows version? I seem to remember Quake ran fractionally slower under Linux.