No it is not. though the 3DES key is three times as long as the DES key, the 3DES block is still exactly the same size as the DES block. A 64 bit block is simply too short, you will get vulnurable to the so called birthday attack.
With a reasonable security margin you can encrypt no more than 512KB with the same key. If you encrypt 35GB with the same key you can be almost sure, that your data is no longer safe.
I'm also wondering if this product even uses a safe mode of operation. It is easy to use a per sector CBC mode with block number as IV (like cryptoloop for Linux), but that is just not secure. A secure solution has to offer some of your disk space and access speed, I think a 10% cost would be likely.
It is not all about the size of RAM. In fact just having a harddisk larger than 2GB is a reason to use a 64 bit architecture. Also imagine those systems that internally measures time in clockcycles, how many seconds will it be before a 32 bit integer overflows? And since time is often meassured in seconds since 1970, internally using clockcycles can be a pain. In fact that computation is soon going to overflow a 64 bit integer.
Why can't we get a 128 bit architecture? A 64 bit physical address space is enough, but a 128 bit logical address space and 128 bit general purpose registers would indeed be nice.
I'd rather see the pain and inefficiency named EIDE be disposed of.
Sure, somebody should make some cheap SCSI drives and controllers. They don't have to be that expensive.
By the use of a redundant sharing. You could split 1MB of data into 128 chunks of 4KB, now you do a redundant coding of those into 256 chunks of 4KB. Each chunk is then numbered, signed, and encrypted. Now you have 256 chunks of each 4192 bytes that you store on 256 different computers. You need to store information about the location which could take up 4KB locally.
Of course a problem remains, where do you keep the metadata needed to find your data? The answer is to store them by similar means and thus building up a tree of nodes. You of course still need to store the root of this tree in a safe location. But the root is simply encrypted and stored in a lot of locations each containing the full data. This piece of data needs an identifier which could be computed as a hash function of your username and password.
If you allocate 2GB for the DIBS - you get 1GB in return
That is basically the idea, though I think it is a litle too optimistic. I'd expect loosing a factor of 4-5 and not just 2.
And while we are at it, please mod parent interesting, I cannot do now that I have answered him.
8.0 is obsolete in less than a year, but 8.1 isn't even out of beta yet!
Yes, let's hope for RedHat that 8.1 gets out of beta before the end of 8.0.
When you have to upgrade your OS more often than you would (otherwise) have to reboot it
Since when was rebooting required when you upgrade? You can upgrade anything but your kernel without a reboot. And if you don't want to reboot at all, support of your current distribution wouldn't help you anyway. If there are critical kernel updates, you have to reboot no matter if you are switching to the next rh7.x kernel or the next rh8.1 kernel. Let's just hope that we will soon see something like kexec used to speed up the reboot process.
There are 12 possible pieces, and thus 12 * 8 = 96 bytes.
OK, I see that it is possible to encode the board in so many bits. And with the litle extra information that is needed, you might even be able to use 100 bytes. Anyway with this encoding most of the possible bitpatterns represent impossible configurations.
Your structure is likely efficient, but a real PITA to work with.
It is compact, it is not interesting for use in actual implementations, more interesting is how compact you can do it, because that gives an upper limit on the number of states.
Don't you mean, increase the cache size, make modules...:)
I think FAT was compiled in my kernel at that time.
perhaps you build it in memory and design it so that you can swap most of it out automatically?
I wonder who really wants to spend a lot of time improving FAT performance when there are so many other filesystems that will always perform better than FAT.
A chessboard is 8x8, meaning 64 spaces. However, each space can contain a pawn, a rook, a bishop, a knight, a king or a queen of either colour.
There can be no more than 32 pieces on the board at any time, and in fact there can be no more than 16 of one color. There can be no more than 2 kings on the board, and there are a lot of other limitiations.
The best estimate for the number of states the board can be in is 2.99x1041.
And that is supposed to mean what? If I multiply those two numbers I get 3112.6 possible states. If you intended to say 2.99*10^1041 you are far off. If you intended to say 2.99*10^41 I still think your estimate is too high.
A naive encoding is 96 bytes per state.
Let's say a tighter, or compressed encoding is 48 bytes per state.
You are too pesimistic. Any encoding I could come up with would be less than 96 bytes, I honestly cannot say how you would be able to use that much. And I can do far better than 48 bytes to encode a state.
My first attempt to come up with an encoding would be just 183bits which is 23 bytes. Here is how I did:
12 bits are needed to store position of the two kings.
62 bits are needed to store information about which of the remaining 62 fields contains a piece.
100 bits are needed to store information about which pieces are in the remaining fields. There can be at most 30 pieces left each of which has 10 different possibilities (5 of each color, empty fields and kings was already taken care of). A group of 3 pieces gives 1000 possibilities which can be encoded in 10 bits, 10 such groups gives 100 bits.
1 bit is needed to know whos turn it is.
4 bits are needed to know which rooks can still be used in a castling.
1 bit is needed to know if en passant is possible.
3 bits are needed to know which pawn can be used in en passant.
This number of bits gives an upper limit on the number of states, though that number is still far beyond the actual number of states because a lot of combinations are not possible, and some are redundant. The most interesting use of a compact encoding is to give an upper limit on the possible number of states, even if you want 100 bytes per state it is not that factor of 100 that is important, but rather the number of possible states.
obviously the words "branching factor" mean nothing to you
Obviously the words "dynamic programming" mean nothing to you.
with computers billions of times more powerful than those we have.
With such powerfull computers we would not be able to compute every possible game, but we would be able to store every possible state. The numbers of states is a lot smaler than the number of games, and the states is all you need to play perfect chess. The best move does not depend on how the state was reached.
Ostensibly your filesystem driver will be caching much of the list information in memory
Caching the tables in physical memory does of course help, but it doesn't remove the linear scan through a linked list. This linear scan takes time even if done in RAM. To improve performance the Linux driver for this filesystem caches a number of already resolved positions, I think this cache holds 8 entries. I found out about that once I needed simultaneous sequential access to 20 files on the same FAT32 filesystem. Performance was horrible. I had two options, either do access in very large blocks to keep the number of listscans low, or increase the cachesize and recompile my kernel. I don't remember which of the two options I chose.
When starting up the application it would complain I had less than 4 MB of memory
I recall some story about a similar bug in MS Basic. If it was used on a PC with more than 512KB of RAM it would say there was not enough RAM. In DOS RAM was measured with a 16bit number counting units of 16 bytes.
Anyone want to bet how much jail time they'll get?
Anyone want to bet whether the military can find the offender? Oh, they can probably find which country it was done from. Does anybody want to call the responsible person a terrorist and start a war against the country?
NTSC/YUV2/stereo: ~111gb for a cinema movie (1hr 45min)
PAL/YUV2/stereo: ~125gb for same
How did you reach those numbers? AFAIK NTSC and PAL use the same line frequency and have the same number of pixels per line, so that would lead to the same size.
Slashdot Mirror
IMO 'xterm' should even be there.
It is just a simple executable you need on the server. You could upload it if you really had to.
Where are my mod points when I need them? That comment was funny. Who dared to moderate it offtopic?
That really doesn't matter. You can use xterm even if they do not run X. It is not the server that needs to run X, it is the client.
In fact I have used xterm in that way (because I had to):
3DES is just fine
No it is not. though the 3DES key is three times as long as the DES key, the 3DES block is still exactly the same size as the DES block. A 64 bit block is simply too short, you will get vulnurable to the so called birthday attack.
With a reasonable security margin you can encrypt no more than 512KB with the same key. If you encrypt 35GB with the same key you can be almost sure, that your data is no longer safe.
I'm also wondering if this product even uses a safe mode of operation. It is easy to use a per sector CBC mode with block number as IV (like cryptoloop for Linux), but that is just not secure. A secure solution has to offer some of your disk space and access speed, I think a 10% cost would be likely.
4 GB of RAM.
It is not all about the size of RAM. In fact just having a harddisk larger than 2GB is a reason to use a 64 bit architecture. Also imagine those systems that internally measures time in clockcycles, how many seconds will it be before a 32 bit integer overflows? And since time is often meassured in seconds since 1970, internally using clockcycles can be a pain. In fact that computation is soon going to overflow a 64 bit integer.
Why can't we get a 128 bit architecture? A 64 bit physical address space is enough, but a 128 bit logical address space and 128 bit general purpose registers would indeed be nice.
I'd rather see the pain and inefficiency named EIDE be disposed of.
Sure, somebody should make some cheap SCSI drives and controllers. They don't have to be that expensive.
Is the "64" just a coinkidink?
What will we see next? The return of Commodore 64?
But the real issue is security and trust.
Of course.
How do you know that your files are safe?
By the use of a redundant sharing. You could split 1MB of data into 128 chunks of 4KB, now you do a redundant coding of those into 256 chunks of 4KB. Each chunk is then numbered, signed, and encrypted. Now you have 256 chunks of each 4192 bytes that you store on 256 different computers. You need to store information about the location which could take up 4KB locally.
Of course a problem remains, where do you keep the metadata needed to find your data? The answer is to store them by similar means and thus building up a tree of nodes. You of course still need to store the root of this tree in a safe location. But the root is simply encrypted and stored in a lot of locations each containing the full data. This piece of data needs an identifier which could be computed as a hash function of your username and password.
If you allocate 2GB for the DIBS - you get 1GB in return
That is basically the idea, though I think it is a litle too optimistic. I'd expect loosing a factor of 4-5 and not just 2.
And while we are at it, please mod parent interesting, I cannot do now that I have answered him.
What bizarre, mythical land of freedom do you live in?
Denmark... It is 37 in our law on copyright.
I'd have modded that comment Insightful. But it already had Score:5, Informative.
Apple don't permit you to hack into the Sorensen codecs and get them to work outside Quicktime Player.
Who needs Apple's permissions? Where I live it is explicitly permitted by law, and the law even says that right cannot be given up by agreement.
Why is TuxRacer not on that list?
Something about this doesn't smell right.
I never liked the smell of tobacco anyway.
Hey shut up! I missed the article last time.
If you are using Gnome I suggest you try SlashApp. It is a ticker-like applet showing headlines from slashdot or gnotices.
I'm sure I saw that exact headline earlier, but it might be more than one day ago.
8.0 is obsolete in less than a year, but 8.1 isn't even out of beta yet!
Yes, let's hope for RedHat that 8.1 gets out of beta before the end of 8.0.
When you have to upgrade your OS more often than you would (otherwise) have to reboot it
Since when was rebooting required when you upgrade? You can upgrade anything but your kernel without a reboot. And if you don't want to reboot at all, support of your current distribution wouldn't help you anyway. If there are critical kernel updates, you have to reboot no matter if you are switching to the next rh7.x kernel or the next rh8.1 kernel. Let's just hope that we will soon see something like kexec used to speed up the reboot process.
There are 12 possible pieces, and thus 12 * 8 = 96 bytes.
OK, I see that it is possible to encode the board in so many bits. And with the litle extra information that is needed, you might even be able to use 100 bytes. Anyway with this encoding most of the possible bitpatterns represent impossible configurations.
Your structure is likely efficient, but a real PITA to work with.
It is compact, it is not interesting for use in actual implementations, more interesting is how compact you can do it, because that gives an upper limit on the number of states.
Don't you mean, increase the cache size, make modules... :)
I think FAT was compiled in my kernel at that time.
perhaps you build it in memory and design it so that you can swap most of it out automatically?
I wonder who really wants to spend a lot of time improving FAT performance when there are so many other filesystems that will always perform better than FAT.
There can be no more than 32 pieces on the board at any time, and in fact there can be no more than 16 of one color. There can be no more than 2 kings on the board, and there are a lot of other limitiations.
The best estimate for the number of states the board can be in is 2.99x1041.
And that is supposed to mean what? If I multiply those two numbers I get 3112.6 possible states. If you intended to say 2.99*10^1041 you are far off. If you intended to say 2.99*10^41 I still think your estimate is too high.
A naive encoding is 96 bytes per state. Let's say a tighter, or compressed encoding is 48 bytes per state.
You are too pesimistic. Any encoding I could come up with would be less than 96 bytes, I honestly cannot say how you would be able to use that much. And I can do far better than 48 bytes to encode a state.
My first attempt to come up with an encoding would be just 183bits which is 23 bytes. Here is how I did:
- 12 bits are needed to store position of the two kings.
- 62 bits are needed to store information about which of the remaining 62 fields contains a piece.
- 100 bits are needed to store information about which pieces are in the remaining fields. There can be at most 30 pieces left each of which has 10 different possibilities (5 of each color, empty fields and kings was already taken care of). A group of 3 pieces gives 1000 possibilities which can be encoded in 10 bits, 10 such groups gives 100 bits.
- 1 bit is needed to know whos turn it is.
- 4 bits are needed to know which rooks can still be used in a castling.
- 1 bit is needed to know if en passant is possible.
- 3 bits are needed to know which pawn can be used in en passant.
This number of bits gives an upper limit on the number of states, though that number is still far beyond the actual number of states because a lot of combinations are not possible, and some are redundant. The most interesting use of a compact encoding is to give an upper limit on the possible number of states, even if you want 100 bytes per state it is not that factor of 100 that is important, but rather the number of possible states.obviously the words "branching factor" mean nothing to you
Obviously the words "dynamic programming" mean nothing to you.
with computers billions of times more powerful than those we have.
With such powerfull computers we would not be able to compute every possible game, but we would be able to store every possible state. The numbers of states is a lot smaler than the number of games, and the states is all you need to play perfect chess. The best move does not depend on how the state was reached.
Do not make jokes about that - it's actually quite true.
.dvi file. I got a surprise the day a friend of mine managed to read the .dvi file I had attached.
Guess what..... I wasn't joking.
I just reply and request the information in an open format.
So do I. Sometimes I send the reply in a
Ostensibly your filesystem driver will be caching much of the list information in memory
Caching the tables in physical memory does of course help, but it doesn't remove the linear scan through a linked list. This linear scan takes time even if done in RAM. To improve performance the Linux driver for this filesystem caches a number of already resolved positions, I think this cache holds 8 entries. I found out about that once I needed simultaneous sequential access to 20 files on the same FAT32 filesystem. Performance was horrible. I had two options, either do access in very large blocks to keep the number of listscans low, or increase the cachesize and recompile my kernel. I don't remember which of the two options I chose.
When starting up the application it would complain I had less than 4 MB of memory
I recall some story about a similar bug in MS Basic. If it was used on a PC with more than 512KB of RAM it would say there was not enough RAM. In DOS RAM was measured with a 16bit number counting units of 16 bytes.
I was searching for porn, "bush" wouldn't be the first word to pop into my head..
Clinton?
Anyone want to bet how much jail time they'll get?
Anyone want to bet whether the military can find the offender? Oh, they can probably find which country it was done from. Does anybody want to call the responsible person a terrorist and start a war against the country?
NTSC/YUV2/stereo: ~111gb for a cinema movie (1hr 45min)
PAL/YUV2/stereo: ~125gb for same
How did you reach those numbers? AFAIK NTSC and PAL use the same line frequency and have the same number of pixels per line, so that would lead to the same size.
2GB in a year or less.
They probably don't write emails but instead write Word documents and attach them to empty emails.