How can that even be called "XML" in the first place? XML has a specific format, described in a standard - and it describes the tags as being in-line with the data. A format that separates them, no matter how useful it might be, is not XML.
What is being stored on disk is not an XML document only in the same sense that foo.xml.gz is not an XML document. Just because you store foo.xml.gz doesn't mean foo.xml stops being XML.
The point of a spec is interoperability. That means there needs to be a consensus. The problem with dictating Theora (or H.264!) is that several vendors aren't willing to implement it.
It would absolutely be better to specify a required format, if everyone were willing to implement it. If not then you get "piece of shit" vendors or vendors implementing "HTML5 except for Theora" -- in either case you don't accomplish anything by adding it to the standard.
Originally used to mean a collection of disks without the coordinated control provided by control software; today the term JBOD most often refers to a cabinet of disks whether or not RAID functionality is present. See disk array.
Note that this actually does *not* match my definition, insofar as it includes shelves with RAID -- but it doesn't even mention spanning!
You are trying to argue that a term with (at least) two different meanings does not have one of those meanings.
I have provided evidence that people do use the term that way. This isn't some random crackpot, it's on the order of 20% of the google results.
What dciginc link?
The fact that links with the first meaning appear higher on a google search than the other only indicates that the one meaning is more common than the other.
I work in the storage industry. If you do too I might be interested in debating this, but otherwise I'll appeal to my authority here.
JBOD, the "RAID" mode, means what you say.
JBOD, the physical object, refers to a device which presents "Just A Bunch Of Disks" rather than doing any sort of RAID. It may, for example, take a bunch of fibre channel disks and put them on a fabric loop, but it would still present the individual disks.
In other words, a JBOD is a generalization of a disk shelf.
Seriously. JBOD is used this way by people who have worked on these things for years.
Yes, I am aware that JBOD is also used to refer to simple spanning. It can also refer to drive shelves/enclosures without a RAID controller, which present "just a bunch of disks".
The OP was asking about enclosures, not RAID levels.
JBOD means "present the drives individually" (as in, don't present them as a single giant possibly RAIDed disk)
I would call your solution a (primitive) JBOD. However, ideally you only need to connect one data cable to the entire shelf, rather than one per individual disk, although that's a little hard to do with SATA. (in contrast to SAS or other SCSI)
Note that this is would only extend a few tens of kilometers. It's to the edge of space, whereas a full elevator is aimed at getting *out* of Earth's gravity well.
They're solving two different problems and aren't really that comparable.
There's the other critical difference that there is A LOT more energy in uranium than in petroleum.
Uranium is not economical to mine because there aren't enough power plants, not because there isn't enough energy in it. There would be A LOT more accessible uranium if its price went up by an order of magnitude.
If it weren't for the moneyed special interests such as the stormpike guard bribing adventurers to participate in their petty land grabs, there probably would be peace between the orcs and the humans.
Is it just me, or is the basic idea really rather obvious? (At least for someone with a basic understanding of both quantum computing and coding theory)
That is, it's fairly obvious you can use convolutional codes with qubits, and if you did you could use the viterbi algorithm to decode it without destroying/measuring the original qubits.
With that said, reliable communication of qubits may be particularly important for scale in quantum computing -- we can build a large quantum computer out of a network of small ones if we can reliably communicate qubits between them.
the effort for error correction is only constant, if the per-bit error probability is constant.
By what mechanism would the per-bit error probability not be constant? (Interesting question)
At worst I'd expect the error probability to not be more than linear, just leaving us at the n^2 case you were referring to earlier.
Anyways, with what has been built so far, not even the underlying theory can be validated. Far too small.
The "underlying theory" is quantum mechanics -- which has held up extremely well thus far. Not that my imagination isn't limited, but it is hard to imagine ways in which quantum computers would/not/ work but anything resembling quantum mechanics would.
In other words, I view the test the other way. We haven't yet been able to build devices that/should/ act as large enough quantum computers to see that they don't. That is, I view impossibility of quantum computing as the surprising result that needs experimental proof! Such proof would be fairly straightforward -- either build something which should function as a quantum computer and see that it doesn't, or find unforeseen fundamental difficulties in the current incremental process. At that point we can step back to quantum mechanics and try to figure out what we've got wrong.
No, because this isn't a quantum computer, in the sense we generally think of it.
It is an interesting device, and at scale it may well be able to do interesting computation. However, there is no reason to believe it can break current asymmetric cryptography.
Real quantum computers will break current asymmetric cryptosystems, although lattice based cryptography is shaping up as a replacement. Quantum computers, afawk, will/not/ break eg AES, although they will provide a quadratic speedup effectively halving the key size -- so if you want your AES encrypted data to be safe against attack by a quantum computer you should use at least 192 bit AES and not 128.
(Note that breaking asymmetric crypto makes doing interesting symmetric crypto hard. Although encrypting your hard drive might be easy, you can't share keys over an untrusted network unless you already have exchanged keys.)
The problem is that tweo of these do basically give you the same maximum problem size as one does.
This only holds if the two computers can only communicate clasically and have no prior entanglement -- and right now we're better at communicating qubits than building them. (see "quantum encryption", which relies on precisely this operation!)
My present impression is that the effort of adding qbits grows quadratically or the like, as each qbit has to be entangled with each other qbit (that is n*n entanglements).
No. It's only a constant amount of work to entangle an unentangled n'th qubit with n-1 others -- any quantum operation will do it.
While you are producing the complicated state you can use error correction to preserve that state, which adds only a constant factor overhead. The problem thus far is that the best techniques previously simply do not scale, although we have plenty of ideas that would. This is largely a matter of engineering, but that takes time.
Slashdot Mirror
How can that even be called "XML" in the first place? XML has a specific format, described in a standard - and it describes the tags as being in-line with the data. A format that separates them, no matter how useful it might be, is not XML.
What is being stored on disk is not an XML document only in the same sense that foo.xml.gz is not an XML document. Just because you store foo.xml.gz doesn't mean foo.xml stops being XML.
And then the spec becomes less useful because fewer vendors implement it.
No it doesn't.
From wikipedia, Java's first release was in 1995 and VB's first release was in 1991.
The point of a spec is interoperability. That means there needs to be a consensus. The problem with dictating Theora (or H.264!) is that several vendors aren't willing to implement it.
It would absolutely be better to specify a required format, if everyone were willing to implement it. If not then you get "piece of shit" vendors or vendors implementing "HTML5 except for Theora" -- in either case you don't accomplish anything by adding it to the standard.
That sounds like a job for killall!
JBOD is a fucking standard.
The closest thing to a standards body I'm aware of for RAID would be SNIA.
http://www.snia.org/education/dictionary/j/
They say:
Originally used to mean a collection of disks without the coordinated control provided by control software; today the term JBOD most often refers to a cabinet of disks whether or not RAID functionality is present. See disk array.
Note that this actually does *not* match my definition, insofar as it includes shelves with RAID -- but it doesn't even mention spanning!
Have you even considered that you might be wrong?
You are trying to argue that a term with (at least) two different meanings does not have one of those meanings.
I have provided evidence that people do use the term that way. This isn't some random crackpot, it's on the order of 20% of the google results.
What dciginc link?
The fact that links with the first meaning appear higher on a google search than the other only indicates that the one meaning is more common than the other.
When I google JBOD, from the *first page* of results:
http://www.aberdeeninc.com/abcatg/kitjbod-1003.htm
http://opensolaris.org/jive/thread.jspa?threadID=83108&tstart=0
http://blogs.sun.com/brendan/entry/jbod_analytics_example
I work in the storage industry. If you do too I might be interested in debating this, but otherwise I'll appeal to my authority here.
JBOD, the "RAID" mode, means what you say.
JBOD, the physical object, refers to a device which presents "Just A Bunch Of Disks" rather than doing any sort of RAID. It may, for example, take a bunch of fibre channel disks and put them on a fabric loop, but it would still present the individual disks.
In other words, a JBOD is a generalization of a disk shelf.
Seriously. JBOD is used this way by people who have worked on these things for years.
Yes, I am aware that JBOD is also used to refer to simple spanning. It can also refer to drive shelves/enclosures without a RAID controller, which present "just a bunch of disks".
The OP was asking about enclosures, not RAID levels.
JBOD means "present the drives individually" (as in, don't present them as a single giant possibly RAIDed disk)
I would call your solution a (primitive) JBOD. However, ideally you only need to connect one data cable to the entire shelf, rather than one per individual disk, although that's a little hard to do with SATA. (in contrast to SAS or other SCSI)
As long as we're at it:
/home /mnt/root /mnt/stuff
/dev/md9 184G 90G 85G 52%
/dev/md8 184G 40G 135G 23%
/dev/md10 2.4T 1.8T 594G 76%
Note that this is would only extend a few tens of kilometers. It's to the edge of space, whereas a full elevator is aimed at getting *out* of Earth's gravity well.
They're solving two different problems and aren't really that comparable.
I'm pretty sure it came out before UO finished it's beta phase.
Legends of Kesmai was just Island of Kesmai with a GUI. IoK dates back to 1985.
It's not the transmission losses, it's the losses at the plant -- which might be as much as 1/3 efficient.
There's the other critical difference that there is A LOT more energy in uranium than in petroleum.
Uranium is not economical to mine because there aren't enough power plants, not because there isn't enough energy in it. There would be A LOT more accessible uranium if its price went up by an order of magnitude.
Unlikely.
You don't risk any data loss, ever, if you shut down your system properly.
That's meaningless, in that you can't completely eliminate the risk of a kernel panic or similar bug.
You're forgetting how big 2^256 is.
Mike Perry's site might (or might not) be a better source than some random blog post that doesn't even link to it.
If it weren't for the moneyed special interests such as the stormpike guard bribing adventurers to participate in their petty land grabs, there probably would be peace between the orcs and the humans.
Is it just me, or is the basic idea really rather obvious? (At least for someone with a basic understanding of both quantum computing and coding theory)
That is, it's fairly obvious you can use convolutional codes with qubits, and if you did you could use the viterbi algorithm to decode it without destroying/measuring the original qubits.
With that said, reliable communication of qubits may be particularly important for scale in quantum computing -- we can build a large quantum computer out of a network of small ones if we can reliably communicate qubits between them.
the effort for error correction is only constant, if the per-bit error probability is constant.
By what mechanism would the per-bit error probability not be constant? (Interesting question)
At worst I'd expect the error probability to not be more than linear, just leaving us at the n^2 case you were referring to earlier.
Anyways, with what has been built so far, not even the underlying theory can be validated. Far too small.
The "underlying theory" is quantum mechanics -- which has held up extremely well thus far. Not that my imagination isn't limited, but it is hard to imagine ways in which quantum computers would /not/ work but anything resembling quantum mechanics would.
In other words, I view the test the other way. We haven't yet been able to build devices that /should/ act as large enough quantum computers to see that they don't. That is, I view impossibility of quantum computing as the surprising result that needs experimental proof! Such proof would be fairly straightforward -- either build something which should function as a quantum computer and see that it doesn't, or find unforeseen fundamental difficulties in the current incremental process. At that point we can step back to quantum mechanics and try to figure out what we've got wrong.
No, because this isn't a quantum computer, in the sense we generally think of it.
It is an interesting device, and at scale it may well be able to do interesting computation. However, there is no reason to believe it can break current asymmetric cryptography.
Real quantum computers will break current asymmetric cryptosystems, although lattice based cryptography is shaping up as a replacement. Quantum computers, afawk, will /not/ break eg AES, although they will provide a quadratic speedup effectively halving the key size -- so if you want your AES encrypted data to be safe against attack by a quantum computer you should use at least 192 bit AES and not 128.
(Note that breaking asymmetric crypto makes doing interesting symmetric crypto hard. Although encrypting your hard drive might be easy, you can't share keys over an untrusted network unless you already have exchanged keys.)
The problem is that tweo of these do basically give you the same maximum problem size as one does.
This only holds if the two computers can only communicate clasically and have no prior entanglement -- and right now we're better at communicating qubits than building them. (see "quantum encryption", which relies on precisely this operation!)
My present impression is that the effort of adding qbits grows quadratically or the like, as each qbit has to be entangled with each other qbit (that is n*n entanglements).
No. It's only a constant amount of work to entangle an unentangled n'th qubit with n-1 others -- any quantum operation will do it.
While you are producing the complicated state you can use error correction to preserve that state, which adds only a constant factor overhead. The problem thus far is that the best techniques previously simply do not scale, although we have plenty of ideas that would. This is largely a matter of engineering, but that takes time.