USB2.0 allows for 480Mbps, which is 55MBps. A high-quality SAS drive will offer 3Gbps (375MBps) at introduction, allowing eventually for 750MBps.
That means, well before we have common petabyte storage, a terabyte disk will take about 22 minutes to clone. A petabyte disk will then take about fifteen days to copy. But by the time we commonly have petabyte storage, it'll likely take no more than a day at the outside to clone a petabyte disk.
Dbus is a system for sending messages. It says nothing about the content or interpretation of the messages. These scripts send messages with a given interpretation. But they don't use dbus; there are issues with calling it from a script.
More like, we have developers developing for one platform, and then package maintainers listing desktop environments as dependencies for a simple media player.
Eventually, some packages will list KDE as a prerequisite, some GNOME, and some Portland, which means I can save precious disk space by using a 10MB Portland shim rather than 150MB of rarely used {GNOME|KDE}.
Moreover, if I wish to create a window manager or desktop environment and have integrated applications, I can simply implement the Portland interface rather than making an explicit wrapper for each toolkit.
So it's just a package management issue, and a simple one at that.
Presumably, the file size information is stored in the filesystem portion of the disk. Since the IFO file is in a predictable location and has a predictable (minimum) length, the DVD player will read it anyway, and continue reading until it finds an EOF. If it was designed that way.
Why don't computers do this? They can. But likely, with buffer issues in mind, and not wanting to reallocate memory often, the programs instead get the file size and then read the contents of the file into an appropriately-sized buffer. (This is just as likely for dedicated DVD players, mind.) So a zero-byte buffer is allocated and 'filled' before it can index the DVD's chapters.
This is a laughable defense, of course, the more so since it's caused by universal good coding practices that are much harder to correct on DVD players than in computer software.
It would require a hardware modification on a trusted computing platform, currently, given that there are no TC auditors continually ensuring compliance. However, when technology improves by one or two orders of magnitude, there may be such auditors.
No, this is a filesystem issue. At worst, you just need to reverse engineer the FS and modify it slightly to mount the modified DVD--and we Linux users would have to do that anyway, so no harm done.
I don't doubt that some DVD players will break on this (namely, those that mounted the DVD as an ISO filesystem rather than simply a raw segment of data, or depending on a particular format). But if you have DVD players that can play the disk, your computer can, too.
The IT department I work in has Win2k for older machines and WinXP for everything that can handle it. We have a ghosting server with five or six images, plus a few Windows install disks in case the images don't work.
When we switch to Vista, which will be when Dell stops selling WinXP boxes or later, we'll simply add a Vista image and tell our employees to use that only on certain models. The added cost will be a few hundred dollars per year.
It's compiled with debug options; you don't expect full performance from that. It will probably take up no more than twice the resources of XP, so perhaps half a gig in idle and a similar processor load.
You could allow direct access to hardware; the only thing you'd want to look out for is the disk. In fact, virtualization would be overkill; you'd want the host/guest distinction and monitoring, but little more than that running by default.
Of course, the host should be able to take over arbitrary hardware temporarily in order to report viruses and such. However, constantly monitoring video card usage is overkill. The program's in memory, after all, and stored on disk.
Someone's building lawn furniture according to the plans you bought for them (patented plans, but you licensed the patents), and they're doing it on your property using materials and tools that you own. You're supposed to enjoy the lawn furniture, but only on the lawn; to make sure this happens, the person locks up the furniture until you want to use it.
You want to use the furniture in your house. So you say you want to use it on the lawn and (given that this furniture-building tenant is quite absent-minded) take it into your living room when his back is turned.
That won't, of course, fly with the RIAA, nor with most any court they choose. But if you're not uploading anything, you only have to worry about their false positive rate. And then you have more urgent and probable things to worry about, such as getting in a car accident.
Or would the countries who have nukes be unable to threaten other nations with them and be forced to deal with equally well armed opponents--perhaps even negotiate?
Socrates had specific questions about what his students said a minute ago. That's not the same thing as assigning a reading and asking nitpicky details about it a week later.
All you're concerned about is matching substrings, right? So you can store hashes of significant-length strings, or even only of significant spans (each paragraph or sentence), thereby reducing your load and your storage; the students don't have their papers in some random entity's control; and there's no worry about leaking out 20 million cruddy papers to throngs of eager high schoolers.
The issue is with creating a (possible) derivative work in the list of hashes.
NOT. The article and writeup claim that court-issued warrants will be easier to get this way, but the article goes on to say that no warrant is required within 90 days of a terrorist attack. Who wants to bet we'll see another minor incident every three months or so from now on?
Then a fork sounds like a good idea. If good politicians are involved, perhaps it could be arranged that one team manages unstable and the other stable/base; you could keep one repository and one installer, but switch between the two with minimum hassle.
This allows separate development of the two and simple reintegration once the base is stable and the new whiz-bang features can safely be added. And the magic of portage means it'd be relatively easy. (Though it'd also be rather simple for most distributions; Portage would probably make it easier to mix and match, though.)
I'll never be able to write Doom 3's equivalent alone, at least not within a reasonable period. A kid might eventually be able to equal or at least approach Beckham's success; it's possible, and people do it--alone.
The first difference is hope.
The second difference is competition. A kid's interested in soccer especially when he can beat all his friends. Doom 3 is a game with singular complexity; implementing it is one task with one difficulty. Playing soccer is as difficult as your opponents, so you can improve by playing people as good as you or better, or massage your ego by picking easy fights.
And the thing is, the fun is when you beat someone slightly better than yourself. If you see Doom 3, you won't be satisfied soon with your games until you write something in three dimensions with decent shadows and textures; but if you're playing soccer, you can find decent opponents for your skill level.
Once you've decided to start programming, then writing a Space Invaders clone can make you positively joyful. But ask a person on the street whether they'd like to do so, and you get a lukewarm response at best.
"Blasphemy #3: Anybody else notice that quantum computers have been proven to be capable of factoring really well, but no one has shown that they can solve any NP-hard algorithms? Come on... factoring isn't NP hard."
There is no proof that it is and no reason to think that it is. We just have no fast algorithm for it.
"Then, there's just some silly stuff I've noticed about crypto. Why do we always seem to use encryption just a generation or so ahead of what is needed to crack it?"
That's largely a matter of key sizes. We choose them according to the hardware we have to brute-force the key; we want our data to be secure for a certain amount of time. And the rest is a matter of the difficulty of finding exploitable weaknesses in the algorithm--that takes time, so the longer the algorithm is used, the more likely it is to be cracked.
"And, why do we encrypt one small block at a time."
If you don't like block ciphers, use a stream cipher. Or create an encryption algorithm that operates on an arbitrary amount of data at once; I just hope you have twice as much RAM as anything you want to encrypt. Simply put, block ciphers are the simplest method we have of scaling an encryption algorithm.
"Each encrypted file usually gives many independent chances to crack the key, and in many cases, some of those blocks have known data."
If the block has known data, then you only need to try different keys until you get that data rather than trying keys until you get sensical data and then trying the key in question on multiple other blocks, but it's only going to be a minor decrease in the amount of time required to crack it. And any worthwhile algorithm will be proof against known plaintext attacks.
"I personally have been trying to prove that no public key system can be NP-hard, but what the heck... I'm not that good."
Take it on a case-by-case basis. Develop exploits for a large number of public key cryptography systems. You might not prove that all public key systems are secure, but you'll definitely destroy confidence in public key cryptography. A pity, though; it's quite useful.
"It seems any time you start talking about crypto, you get assailed by experts telling you just how full of it you are. Consider something simple, like generation of random numbers."
Well, you're not an expert, so you actually are full of it. Hardware RNGs aren't difficult to make; it's just that no computer company has found it worthwhile to market them on a large scale; DPRNGs are difficult to make, but since we don't deploy hardware RNGs on a large scale, they are necessary.
Don't like it? Use Linux, get a hardware RNG, and direct its input to/dev/random. Then modify your software to use that rather than its cryptographically secure DPRNG.
Slashdot Mirror
USB2.0 allows for 480Mbps, which is 55MBps. A high-quality SAS drive will offer 3Gbps (375MBps) at introduction, allowing eventually for 750MBps.
That means, well before we have common petabyte storage, a terabyte disk will take about 22 minutes to clone. A petabyte disk will then take about fifteen days to copy. But by the time we commonly have petabyte storage, it'll likely take no more than a day at the outside to clone a petabyte disk.
As for bad blocks, use an internal RAID.
A short script involving indent, listing, and latex2html would do the trick. That's more piping than reinventing.
http://backpan.perl.org/authors/id/C/CH/CHTTRAX/ provides listing, which converts C++ or Perl to LaTeX. If you want a solution for other languages, well, no ideas.
Dbus is a system for sending messages. It says nothing about the content or interpretation of the messages. These scripts send messages with a given interpretation. But they don't use dbus; there are issues with calling it from a script.
More like, we have developers developing for one platform, and then package maintainers listing desktop environments as dependencies for a simple media player.
Eventually, some packages will list KDE as a prerequisite, some GNOME, and some Portland, which means I can save precious disk space by using a 10MB Portland shim rather than 150MB of rarely used {GNOME|KDE}.
Moreover, if I wish to create a window manager or desktop environment and have integrated applications, I can simply implement the Portland interface rather than making an explicit wrapper for each toolkit.
So it's just a package management issue, and a simple one at that.
Presumably, the file size information is stored in the filesystem portion of the disk. Since the IFO file is in a predictable location and has a predictable (minimum) length, the DVD player will read it anyway, and continue reading until it finds an EOF. If it was designed that way.
Why don't computers do this? They can. But likely, with buffer issues in mind, and not wanting to reallocate memory often, the programs instead get the file size and then read the contents of the file into an appropriately-sized buffer. (This is just as likely for dedicated DVD players, mind.) So a zero-byte buffer is allocated and 'filled' before it can index the DVD's chapters.
This is a laughable defense, of course, the more so since it's caused by universal good coding practices that are much harder to correct on DVD players than in computer software.
It would require a hardware modification on a trusted computing platform, currently, given that there are no TC auditors continually ensuring compliance. However, when technology improves by one or two orders of magnitude, there may be such auditors.
No, this is a filesystem issue. At worst, you just need to reverse engineer the FS and modify it slightly to mount the modified DVD--and we Linux users would have to do that anyway, so no harm done.
I don't doubt that some DVD players will break on this (namely, those that mounted the DVD as an ISO filesystem rather than simply a raw segment of data, or depending on a particular format). But if you have DVD players that can play the disk, your computer can, too.
The IT department I work in has Win2k for older machines and WinXP for everything that can handle it. We have a ghosting server with five or six images, plus a few Windows install disks in case the images don't work.
When we switch to Vista, which will be when Dell stops selling WinXP boxes or later, we'll simply add a Vista image and tell our employees to use that only on certain models. The added cost will be a few hundred dollars per year.
It's compiled with debug options; you don't expect full performance from that. It will probably take up no more than twice the resources of XP, so perhaps half a gig in idle and a similar processor load.
You could allow direct access to hardware; the only thing you'd want to look out for is the disk. In fact, virtualization would be overkill; you'd want the host/guest distinction and monitoring, but little more than that running by default.
Of course, the host should be able to take over arbitrary hardware temporarily in order to report viruses and such. However, constantly monitoring video card usage is overkill. The program's in memory, after all, and stored on disk.
Let's try extending the analogy.
Someone's building lawn furniture according to the plans you bought for them (patented plans, but you licensed the patents), and they're doing it on your property using materials and tools that you own. You're supposed to enjoy the lawn furniture, but only on the lawn; to make sure this happens, the person locks up the furniture until you want to use it.
You want to use the furniture in your house. So you say you want to use it on the lawn and (given that this furniture-building tenant is quite absent-minded) take it into your living room when his back is turned.
That won't, of course, fly with the RIAA, nor with most any court they choose. But if you're not uploading anything, you only have to worry about their false positive rate. And then you have more urgent and probable things to worry about, such as getting in a car accident.
Look for it on Make next week.
Or would the countries who have nukes be unable to threaten other nations with them and be forced to deal with equally well armed opponents--perhaps even negotiate?
Is your goal to reduce bloodshed or tyranny?
Why do you think the world exists in the first place? Not for humans, surely!
Socrates had specific questions about what his students said a minute ago. That's not the same thing as assigning a reading and asking nitpicky details about it a week later.
All you're concerned about is matching substrings, right? So you can store hashes of significant-length strings, or even only of significant spans (each paragraph or sentence), thereby reducing your load and your storage; the students don't have their papers in some random entity's control; and there's no worry about leaking out 20 million cruddy papers to throngs of eager high schoolers.
The issue is with creating a (possible) derivative work in the list of hashes.
Great--they're still asking for warrants.
NOT. The article and writeup claim that court-issued warrants will be easier to get this way, but the article goes on to say that no warrant is required within 90 days of a terrorist attack. Who wants to bet we'll see another minor incident every three months or so from now on?
Then a fork sounds like a good idea. If good politicians are involved, perhaps it could be arranged that one team manages unstable and the other stable/base; you could keep one repository and one installer, but switch between the two with minimum hassle.
This allows separate development of the two and simple reintegration once the base is stable and the new whiz-bang features can safely be added. And the magic of portage means it'd be relatively easy. (Though it'd also be rather simple for most distributions; Portage would probably make it easier to mix and match, though.)
I'll never be able to write Doom 3's equivalent alone, at least not within a reasonable period. A kid might eventually be able to equal or at least approach Beckham's success; it's possible, and people do it--alone.
The first difference is hope.
The second difference is competition. A kid's interested in soccer especially when he can beat all his friends. Doom 3 is a game with singular complexity; implementing it is one task with one difficulty. Playing soccer is as difficult as your opponents, so you can improve by playing people as good as you or better, or massage your ego by picking easy fights.
And the thing is, the fun is when you beat someone slightly better than yourself. If you see Doom 3, you won't be satisfied soon with your games until you write something in three dimensions with decent shadows and textures; but if you're playing soccer, you can find decent opponents for your skill level.
Once you've decided to start programming, then writing a Space Invaders clone can make you positively joyful. But ask a person on the street whether they'd like to do so, and you get a lukewarm response at best.
If data compression is being handled in the kernel, there are serious design issues here.
And in this case, being 'extra careful' consists of writing sufficient tests.
"Blasphemy #3: Anybody else notice that quantum computers have been proven to be capable of factoring really well, but no one has shown that they can solve any NP-hard algorithms? Come on... factoring isn't NP hard."
/dev/random. Then modify your software to use that rather than its cryptographically secure DPRNG.
There is no proof that it is and no reason to think that it is. We just have no fast algorithm for it.
"Then, there's just some silly stuff I've noticed about crypto. Why do we always seem to use encryption just a generation or so ahead of what is needed to crack it?"
That's largely a matter of key sizes. We choose them according to the hardware we have to brute-force the key; we want our data to be secure for a certain amount of time. And the rest is a matter of the difficulty of finding exploitable weaknesses in the algorithm--that takes time, so the longer the algorithm is used, the more likely it is to be cracked.
"And, why do we encrypt one small block at a time."
If you don't like block ciphers, use a stream cipher. Or create an encryption algorithm that operates on an arbitrary amount of data at once; I just hope you have twice as much RAM as anything you want to encrypt. Simply put, block ciphers are the simplest method we have of scaling an encryption algorithm.
"Each encrypted file usually gives many independent chances to crack the key, and in many cases, some of those blocks have known data."
If the block has known data, then you only need to try different keys until you get that data rather than trying keys until you get sensical data and then trying the key in question on multiple other blocks, but it's only going to be a minor decrease in the amount of time required to crack it. And any worthwhile algorithm will be proof against known plaintext attacks.
"I personally have been trying to prove that no public key system can be NP-hard, but what the heck... I'm not that good."
Take it on a case-by-case basis. Develop exploits for a large number of public key cryptography systems. You might not prove that all public key systems are secure, but you'll definitely destroy confidence in public key cryptography. A pity, though; it's quite useful.
"It seems any time you start talking about crypto, you get assailed by experts telling you just how full of it you are. Consider something simple, like generation of random numbers."
Well, you're not an expert, so you actually are full of it. Hardware RNGs aren't difficult to make; it's just that no computer company has found it worthwhile to market them on a large scale; DPRNGs are difficult to make, but since we don't deploy hardware RNGs on a large scale, they are necessary.
Don't like it? Use Linux, get a hardware RNG, and direct its input to
I hope you have five gigabytes of RAM to store a DVD image to burn.
Or maybe you do want a hard drive after all?
Chibi + detail = monster. Especially with the long fingers and the dumpy body.
For a Windows driver? Hell yeah. It'd be hard enough to pay for a cup of coffee.
Or you don't care and you deny responsibility when your machine is being abused. That's the most popular way.