First, Moore's law is not a law, but an observation. It's unlikely to hold for long, as CPUs run into limitations like the speed of light (currently a problem already).
But okay, 128 bits might be breakable given enough time after all. I'm not all that sure that anybody will bother spending that many resources though.
We can try a 256 bit key for example. It is estimated that there are 1.7 x 10^77 atoms in the universe. Pretty big number, but 2^256 is about 1.1 x 10^77. Add a few bits more, say, 512 bit key, and the universe might not even exist by the time that space is searched, even using every atom in it.
Haha. 128 bit symmetric encryption is unbreakable by brute force, no matter how much computing power you have. In 150 years all the computing capability of the planet won't be able to search even 1% of the key space.
That's of course assuming nobody finds a faster way than brute force.
The problem with that is that AI is not such a direct thing as rendering graphics. AI implementations vary a lot, and depend a lot on the world's state.
In order to accelerate AI, you'd have to make a chip that would accelerate some very used part of it, and what would that be? Perhaps a chip could accelerate neural networks. The problem is that while every 3D engine ends rendering polygons not every AI is a neural network.
Completely agreed about that. That's why I'm quite annoyed with the lack of new turn based games. At least in those games could be played on equal terms.
I actually considered trying to code a fair RTS by giving the computer a "virtual mouse". This way it would have to play a lot more like a player, and could have a chance of missing with it. Never got to do it, unfortunately.
Starcraft is a RTS, and in a RTS omniscience and omnipresence would be a quite nice advantage. Put simply: The AI is never distracted, knows the position of every unit, and the progress of every operation and every resource.
Now, combine that with a decent AI implementation that can use elements of the game to its advantage, and it shouldn't be that hard to code something that would crush newbies without much trouble.
I'd be more impressed if it was turn based, since that would make competition on equal terms perfectly possible. I remember the AI in X-Com used to give me quite a lot of trouble.
I'm not completely sure, but I think Total Annihilation doesn't cheat. Or at least you can beat it by destroying its resource collectors.
I've seen several games where you could kill the harvester or whatever, and it never seemed to make much of an effect on the computer, but in TA the strategy worked just fine for me.
Maybe you used SourceSafe. I tried it. It was really horrible.
I tried several systems. Here's what I think: No source control: BAD. SourceSafe: Just almost as bad. Could actually be worse. It can destroy productivity, and has lots of limitations. There's the dreaded database corruption issue, too... CVS: Decent. Not wonderful, but a lot better than any of the above SVN: Great. Similar interface to CVS, fixes a lot of limitations, works better.
If you use CVS or SVN, a modem shouldn't be a big problem. It's source code, after all. Excepting global search/replace changes over the whole repository, it's hard to do anything that takes more than a minute or two for SVN to transfer over a modem connection.
SourceSafe is *really* slow. CVS is okay, but SVN is faster due to a better design. So use it if you can. It will save you a lot more time than you lose by waiting a minute or two for a checkout to finish.
You have an online processing system, something you say is very important, and you don't have the source. You yourself might have no use for it. But think of this:
1. You're in a vulnerable position. They have the keys to part of your business, so to speak. That's bad.
2. Continuing with the first point, if you ever need to change this system later, and they refuse, or go bankrupt you'll be in big trouble.
3. You don't know what's in that code, nor can find it easily. It doesn't have to be malicious, but it could be very incompetently written, with lots of security problems. The obfuscation will prevent you from seeing that, or from having somebody else fix it.
4. Don't outsource critical infrastructure! If the company sells something, then it should do the selling itself, not trusting somebody else not to screw up that.
Nonsense. I had my server up for 360 days without rebooting, with kernel 2.4. It had 360 days on the uptime counter. I only shut it down because it was too slow for the newer stuff I wanted to run.
I'd recommend simply buying/getting a Linux/Unix manual.
Those can contain lots of useful stuff. A distro manual is probably a bad idea though, you'd want something that properly explains the administration of an Unix system in the generic way - with the command line.
Whatever the distro, some things remain constant, such as/etc/hosts,/etc/nsswitch.conf and commands like 'du'. A generic manual can contain lots of useful info about things like that.
Excuse me, but "soul" and all of that is nonsense.
Music is simply a lot of nice sounding variations in the pressure of air, whether performed by a musician or a MP3 player. My father, who plays the viola in the spanish orchestra, has a fairly large CD collection, and I've never heard him say that CD recordings lack "soul" or anything like that.
It's not like this is such a new idea either. Player pianos and musical boxes are quite old inventions, for instance. I've yet to hear anybody describe a musical box as "insulting". They don't sound like a musician of course, but not because of the lack of "soul", but because they weren't exact enough. This is simply the same thing, except made with new technology.
Now, the merits of this versus simply recording the dance on tape are more debatable. I'm sure that eventually we'll manage to build a robot that can teach dancing. Then it'll certainly be very interesting.
There's too much 3D shooter lately. There are some decent games, but a lot of them just repeat the same old stuff with better graphics.
One great game I played recently was Sacrifice (Shiny). It's just great. The game you play is a story that the protagonist tells. The creature are all really strange, done with this style Shiny uses that's quite unique. The replayability is nice as well, with the wizard gaining different powers depending on the missions that are done.
Graphically, these days it's not that impressive. The mechanics themselves are simple. And still, it's really, really good.
Scenario 1 and 3 are quite different. Look at it from inside the organization.
Scenario 1: Damn! We've got to fix that one before out customers start getting hacked!
Scenario 3: No big deal, the policy is to keep the exploit secret for 30 days. We can add that to the queue of things to do.
The problem is that the blackhats aren't going to wait. Given enough time, which can easily be measured in days or even hours, Scenario 3 can become Scenario 2. And then you're in big trouble.
As an admin, some organization assuring me they know of an exploit which has been secretly reported to them does very little for my peace of mind. I want to know what is it so that I can test my systems, put a rule on the firewall, or at least do something while they're working on it.
Most security exploits are just another buffer overrun, or just another race. That stuff can be fixed in a matter of 5-60 minutes by a competent developer. Lots of things can happen in 90 days, and the black hats definitely won't give you that long.
I'd give 3 or 5 days maximum. There's no reason why a patch can't be made in that time.
And why exactly does the server allow all of that?
It's not that hard to keep track of ammo server side, as well as checking for the other things you mentioned. Of course make it completely hack-proof is impossible, but the things you mentioned are hardly impossible to defend against.
Why the "this device must accept any interference received" part? What exactly does it mean, and why couldn't a device somehow protect itself from interference?
A really fast Random Number Generator A *really* fast AES implementation in the CPU
It could be used for DRM of course, but I doubt it. All it does is to accelerate crypto. If you want to encrypt the whole disk then this would let you do it with almost no difference in performance. OpenSSL can be patched to use it, which would be nice for a server that uses SSL heavily.
The speed of light is 300000 km/s. Geostationary orbit is at 35786 km. That is, for the signal to go up and back down you lose 237ms. Really bad for something like Quake, but not all that horrible for web browsing/downloading.
I've heard satellite internet has often latencies in the order of seconds though, so there's got to be something else there.
Well, you'd fry the electronics. You wouldn't do any damage to the data, as even if current got to the drive's head it's parked in a place without data when the drive's off.
So, the manufacturer gets the drive, swaps the platter into a new chassis, and you have the same problem as before. What you could to do instead is to apply a really strong magnetic field to the drive. That should erase the data on the platters, and shouldn't be noticeable.
A hard drive can't work in a vacuum, though. They rely on an air cushion keeping the head floating a minuscule distance above the platter. Without the air you'd get a head crash.
Helps quite a lot of course. That's why it's a very good idea to have lots of RAM. Any unused memory is used for disk cache in a modern OS.
The cache present on the drive IMHO is much less important, although I've heard that it can help make things smoother. Internal cache is used mostly for keeping the readahead. It's probably a bit better used by the drive than the cache in RAM because the drive has more knowledge about its internals than the computer, but I'd rather get extra RAM than extra on-drive cache.
Technical issues. It's hard to spin a platter at 10K RPM. It also requires cooling, and makes lots of noise too. 7200 is about the most you can use without having a fan blow on the HDD, and I would prefer not to because they get quite hot. I suppose the manufacturers picture lots of users buying a 10K RPM drive, sticking it into an under-ventilated box and getting a replacement a week later because it died from overheating.
There's also that RPM is not the only way of making things faster. Basically, the performance of a hard disk is determined by 3 variables:
Rotational latency: The time it takes for the disk to spin into the right position. That is, once the head is on the right place, this is how long it has to wait for the data to pass under it. More RPM translates into less rotational latency.
Seeking latency: The time it takes for the drive's assembly to get into the right position.
These two are often added up in the statistics. Solid state drives pretty much lack them. I'm setting up now a firewall that boots from CompactFlash on CF-IDE adapter, and it boots really fast despite a transfer rate of only 2 MB/s. Latency can add up to quite a lot.
Data rate: The speed at which the drive reads or writes data once everything is in the right place. This is a function of the RPM and data density. More speed means the data passes under the heads faster. More density means there's more data per square inch.
So, increasing RPM is one way of getting more performance. The other one is packing more data into the same place. Some drives have small platters for this reason. This also means that a bigger drive is often also faster than a smaller one, given identical RPM, platter size, and number of platters.
Slashdot Mirror
Hence the last line of my post, where I say that this would only work as long as nobody finds a faster method than brute force.
So indeed in my post I'm assuming that there's no faster way to crack it.
A little problem with that:
First, Moore's law is not a law, but an observation. It's unlikely to hold for long, as CPUs run into limitations like the speed of light (currently a problem already).
But okay, 128 bits might be breakable given enough time after all. I'm not all that sure that anybody will bother spending that many resources though.
We can try a 256 bit key for example. It is estimated that there are 1.7 x 10^77 atoms in the universe. Pretty big number, but 2^256 is about 1.1 x 10^77. Add a few bits more, say, 512 bit key, and the universe might not even exist by the time that space is searched, even using every atom in it.
Haha. 128 bit symmetric encryption is unbreakable by brute force, no matter how much computing power you have. In 150 years all the computing capability of the planet won't be able to search even 1% of the key space.
That's of course assuming nobody finds a faster way than brute force.
The problem with that is that AI is not such a direct thing as rendering graphics. AI implementations vary a lot, and depend a lot on the world's state.
In order to accelerate AI, you'd have to make a chip that would accelerate some very used part of it, and what would that be? Perhaps a chip could accelerate neural networks. The problem is that while every 3D engine ends rendering polygons not every AI is a neural network.
Completely agreed about that. That's why I'm quite annoyed with the lack of new turn based games. At least in those games could be played on equal terms.
I actually considered trying to code a fair RTS by giving the computer a "virtual mouse". This way it would have to play a lot more like a player, and could have a chance of missing with it. Never got to do it, unfortunately.
Not very surprising, really.
Starcraft is a RTS, and in a RTS omniscience and omnipresence would be a quite nice advantage. Put simply: The AI is never distracted, knows the position of every unit, and the progress of every operation and every resource.
Now, combine that with a decent AI implementation that can use elements of the game to its advantage, and it shouldn't be that hard to code something that would crush newbies without much trouble.
I'd be more impressed if it was turn based, since that would make competition on equal terms perfectly possible. I remember the AI in X-Com used to give me quite a lot of trouble.
I'm not completely sure, but I think Total Annihilation doesn't cheat. Or at least you can beat it by destroying its resource collectors.
I've seen several games where you could kill the harvester or whatever, and it never seemed to make much of an effect on the computer, but in TA the strategy worked just fine for me.
Maybe you used SourceSafe. I tried it. It was really horrible.
I tried several systems. Here's what I think:
No source control: BAD.
SourceSafe: Just almost as bad. Could actually be worse. It can destroy productivity, and has lots of limitations. There's the dreaded database corruption issue, too...
CVS: Decent. Not wonderful, but a lot better than any of the above
SVN: Great. Similar interface to CVS, fixes a lot of limitations, works better.
If you use CVS or SVN, a modem shouldn't be a big problem. It's source code, after all. Excepting global search/replace changes over the whole repository, it's hard to do anything that takes more than a minute or two for SVN to transfer over a modem connection.
SourceSafe is *really* slow. CVS is okay, but SVN is faster due to a better design. So use it if you can. It will save you a lot more time than you lose by waiting a minute or two for a checkout to finish.
Whoa. Just think about what you said.
You have an online processing system, something you say is very important, and you don't have the source. You yourself might have no use for it. But think of this:
1. You're in a vulnerable position. They have the keys to part of your business, so to speak. That's bad.
2. Continuing with the first point, if you ever need to change this system later, and they refuse, or go bankrupt you'll be in big trouble.
3. You don't know what's in that code, nor can find it easily. It doesn't have to be malicious, but it could be very incompetently written, with lots of security problems. The obfuscation will prevent you from seeing that, or from having somebody else fix it.
4. Don't outsource critical infrastructure! If the company sells something, then it should do the selling itself, not trusting somebody else not to screw up that.
Nonsense. I had my server up for 360 days without rebooting, with kernel 2.4. It had 360 days on the uptime counter. I only shut it down because it was too slow for the newer stuff I wanted to run.
<post>
<quote>
<answer type=long>
<content="NO!!!!!!!!!">
<answer>
</quote>
<content type="reply" length="unnecessarily long">
<font family="Sans Serif">
<pedantic>
Actually it would probably look more like this:
<scream pitch="high">NO!!!!!!!!!!</scream>
</pedantic>
</font>
<hack type="avoid lameness filter">
sohghogheis7cohquetueMohaeyaizee
ohh9kaithahNgueghohbiezahgaihuvu
iag0Ezishaibukoovuishaicawaechae
Oothusitia8tikochobomiphahghogei
eeX1eetioxaehiquahbaidaupuacepah
Iniem9quietoonguudaiqueibahceing
quoh0eoYeisohsohpouvouxekulaenga
aCh1iacheeroataevaileifozaiqueic
aelaikuNe0sailaetheephoomoateehu
</hack>
</content>
</post>
I'd recommend simply buying/getting a Linux/Unix manual.
/etc/hosts, /etc/nsswitch.conf and commands like 'du'. A generic manual can contain lots of useful info about things like that.
Those can contain lots of useful stuff. A distro manual is probably a bad idea though, you'd want something that properly explains the administration of an Unix system in the generic way - with the command line.
Whatever the distro, some things remain constant, such as
Excuse me, but "soul" and all of that is nonsense.
Music is simply a lot of nice sounding variations in the pressure of air, whether performed by a musician or a MP3 player. My father, who plays the viola in the spanish orchestra, has a fairly large CD collection, and I've never heard him say that CD recordings lack "soul" or anything like that.
It's not like this is such a new idea either. Player pianos and musical boxes are quite old inventions, for instance. I've yet to hear anybody describe a musical box as "insulting". They don't sound like a musician of course, but not because of the lack of "soul", but because they weren't exact enough. This is simply the same thing, except made with new technology.
Now, the merits of this versus simply recording the dance on tape are more debatable. I'm sure that eventually we'll manage to build a robot that can teach dancing. Then it'll certainly be very interesting.
Well, from Celestia at least the Sun indeed looks tiny when looking from Titan.
I imagine that the camera they use adapts the exposition time as needed.
There's too much 3D shooter lately. There are some decent games, but a lot of them just repeat the same old stuff with better graphics.
One great game I played recently was Sacrifice (Shiny). It's just great. The game you play is a story that the protagonist tells. The creature are all really strange, done with this style Shiny uses that's quite unique. The replayability is nice as well, with the wizard gaining different powers depending on the missions that are done.
Graphically, these days it's not that impressive. The mechanics themselves are simple. And still, it's really, really good.
Scenario 1 and 3 are quite different. Look at it from inside the organization.
Scenario 1: Damn! We've got to fix that one before out customers start getting hacked!
Scenario 3: No big deal, the policy is to keep the exploit secret for 30 days. We can add that to the queue of things to do.
The problem is that the blackhats aren't going to wait. Given enough time, which can easily be measured in days or even hours, Scenario 3 can become Scenario 2. And then you're in big trouble.
As an admin, some organization assuring me they know of an exploit which has been secretly reported to them does very little for my peace of mind. I want to know what is it so that I can test my systems, put a rule on the firewall, or at least do something while they're working on it.
Huh? 90 days? What for?
Most security exploits are just another buffer overrun, or just another race. That stuff can be fixed in a matter of 5-60 minutes by a competent developer. Lots of things can happen in 90 days, and the black hats definitely won't give you that long.
I'd give 3 or 5 days maximum. There's no reason why a patch can't be made in that time.
And why exactly does the server allow all of that?
It's not that hard to keep track of ammo server side, as well as checking for the other things you mentioned. Of course make it completely hack-proof is impossible, but the things you mentioned are hardly impossible to defend against.
One thing I never understood.
Why the "this device must accept any interference received" part? What exactly does it mean, and why couldn't a device somehow protect itself from interference?
Padlock, from what I've seen is two things:
A really fast Random Number Generator
A *really* fast AES implementation in the CPU
It could be used for DRM of course, but I doubt it. All it does is to accelerate crypto. If you want to encrypt the whole disk then this would let you do it with almost no difference in performance. OpenSSL can be patched to use it, which would be nice for a server that uses SSL heavily.
Nope, the speed of light isn't the problem.
The speed of light is 300000 km/s. Geostationary orbit is at 35786 km. That is, for the signal to go up and back down you lose 237ms. Really bad for something like Quake, but not all that horrible for web browsing/downloading.
I've heard satellite internet has often latencies in the order of seconds though, so there's got to be something else there.
Well, you'd fry the electronics. You wouldn't do any damage to the data, as even if current got to the drive's head it's parked in a place without data when the drive's off.
So, the manufacturer gets the drive, swaps the platter into a new chassis, and you have the same problem as before. What you could to do instead is to apply a really strong magnetic field to the drive. That should erase the data on the platters, and shouldn't be noticeable.
A hard drive can't work in a vacuum, though. They rely on an air cushion keeping the head floating a minuscule distance above the platter. Without the air you'd get a head crash.
Helps quite a lot of course. That's why it's a very good idea to have lots of RAM. Any unused memory is used for disk cache in a modern OS.
The cache present on the drive IMHO is much less important, although I've heard that it can help make things smoother. Internal cache is used mostly for keeping the readahead. It's probably a bit better used by the drive than the cache in RAM because the drive has more knowledge about its internals than the computer, but I'd rather get extra RAM than extra on-drive cache.
Technical issues. It's hard to spin a platter at 10K RPM. It also requires cooling, and makes lots of noise too. 7200 is about the most you can use without having a fan blow on the HDD, and I would prefer not to because they get quite hot. I suppose the manufacturers picture lots of users buying a 10K RPM drive, sticking it into an under-ventilated box and getting a replacement a week later because it died from overheating.
There's also that RPM is not the only way of making things faster. Basically, the performance of a hard disk is determined by 3 variables:
Rotational latency: The time it takes for the disk to spin into the right position. That is, once the head is on the right place, this is how long it has to wait for the data to pass under it. More RPM translates into less rotational latency.
Seeking latency: The time it takes for the drive's assembly to get into the right position.
These two are often added up in the statistics. Solid state drives pretty much lack them. I'm setting up now a firewall that boots from CompactFlash on CF-IDE adapter, and it boots really fast despite a transfer rate of only 2 MB/s. Latency can add up to quite a lot.
Data rate: The speed at which the drive reads or writes data once everything is in the right place. This is a function of the RPM and data density. More speed means the data passes under the heads faster. More density means there's more data per square inch.
So, increasing RPM is one way of getting more performance. The other one is packing more data into the same place. Some drives have small platters for this reason. This also means that a bigger drive is often also faster than a smaller one, given identical RPM, platter size, and number of platters.