Generally in spoken english, the use of the exclusive or is indicated by prefixing the predicate with 'either'.
For instance: 'i will find either the keys to the car or the truck' implies that you will find one, but not the other. Whereas, 'i will find the keys to the car, or the keys to the truck' does not have this limitation. I imagine that most people would consider this predicate satisfied if they found that both sets of keys were hiding under the same cushion on the sofa.
Not wanting to be a pedant, but that's not the TOC. That's the first meg of the filesystem, which contains the directory structure and probably the first 900k worth of data.
The TOC is stored in the beginning of the disc in unaddressable sectors, in an area known as the PMA (Program Memory Area.) Also in this area is the ATIP and the OPC zone (on recordables.)
The TOC itself is merely a list of track/offset/length/mode/form AVPs which describe the format of the CD.
Note that in the case of multisession discs, there's more than one TOC, and more than one actual ISO filesystem. The most recent TOC is read (linked to from the original TOC), and the ISO image in this session is read. It posesses a complete filesystem structure for all the files, but the sector offsets for files in previous sessions cause the drive to seek to the previous sessions when file lookups are done.
On VHS tapes, Macrovision works by exploiting the gain control circuitry (mandatory if you want to brand your player as VHS as far as I recall.)
The way it works is that there's about 30-40 scanlines above the picture (hence, not displayed on the television) which are used for signalling, subtitles, supertext, etc. Macrovision makes one or two of the pixels in this area oscillate between being really really bright, and really really dark. The AGC circuitry in the VCR compensates by either dimming or brightening the picture.
So, it's not a 'bit you set' on a VHS. On a DVD it is, and yeah, i think you have to pay some stupid organization for the 'rights' to set that bit in your encrypted content and get them to sign it, or something. On VHS, the methodology is probably still patented, but anybody COULD trivially implement it.
The Cane Toad was introduced to eat the Cane Beetle, which was causing sugar farmers great degrees of grief.
For some bizarre reason, the toad wasn't even vaguely interested in eating the grub, but did prove successful at agressively outcompeting fucktons of native species, many of which have since become extinct.
Now, the toad is apparently making inroads on kakadu.
It would be funny, however, if we introduced a virus to kill all the toads and the virus killed something else again, like people.
Appletalk is routable, for what its worth. A DDP address will look like two numbers separated by a dot. The first number is the 'zone' (I think, it's been a while,) which is analagous to a subnet. The second number is the endpoint address.
Ciscos support propagation of appletalk routing info via EIGRP as well as Appletalk's native protocol.
Just cos Linux won't route appletalk by default (although you can easily configure linux to do it), don't assume that appletalk isn't routable.
No. I was prepared to be open minded until that last bit.
The only reason that we still HAVE jesus' teachings, if such they are, is that ANYBODY could reproduce the New Testament (and the torah which preceeded it) for no cost. Had it been copyrighted, distribution rights would have been limited to a select oligarchy who would only have reproduced it until such time as it was no longer commercially viable.
Owing to the nature of religous texts as self-propagating viral memes, they are unlikely to get corrupted by the faithful, except during translation. The book of revelations even threatens retributions against those who modify the christian bible (and, the Qu'ran claims to be an exact copy of a book in heaven, et cetera.)
Note: I don't follow an organized religion, I'm just interested in these subjects.
It seems amusing that, despite your obvious intelligence, you've become a slavering rondroid. Get out while you can still sort of think for yourself.
The ethernet PHY will be running at 10MHz, 1 bit/cycle.
The bus interface will be running at 1.79MHz (or some multiple/fraction thereof), at 8 bits in parallel.
Assuming good buffering, you could very easily saturate an 8 bit 1.79MHz bus with the output from a 10MHz serial line (which is essentially all that ethernet's PHY is.)
It's unlikely it'd be a different controller. Chances are it's simply a different ram chip or two, combined possibly with a field or two in the firmware config set differently.
Admittedly, the differences are non-trivial, but the production cost for either would not vary by more than a dollar per unit, either way.
I've never had any probs with sub-10 Gig IDE disks. That said, I've had no fewer than three 30 Gig Seagate ATA66 disks collapse on me, and was burned by the 60GXP problem after I switched from Seagate to IBM as a result.
With that in mind, the only SCSI drives i've ever blown up have been the early 7200RPM Seagate Barracudas (32550 and 15150 series), which have died thermal deaths after years of constant service.
An interesting observation: These days, IDE disks seem to be built in multiples of 10GB (e.g. 10GB, 20GB, 40GB, 80GB etc) and SCSI disks come in multiples of 9GB (9, 18, 36, 72 etc.) Are they simply the same disks with a different sector sparing scheme/controller, but more reliable because they have more spare sectors? It wouldn't surprise me...
The same reason that Intel has been locking their multipliers since the p2-233 came out. If you make product X with fixed cost Cx, sell it for Rx, which is Cx+20%, and don't have a higher-spec product, it makes sense to introduce brain-dead product Y, which you build for the same fixed cost (Cy=Cx), but sell for Cy+20% and jack up the Rx to Cx+40 or 50%.
The WD 'special edition' drives are a good example. Several tens of dollars more for $2 worth of semiconductors.
Another good example was the Celeron 300s and 400s, most of which were capable of running at at least 450 mhz, but due to multiplier locking issues, only the 300 (which could be run at 4.5x100) was up to it. Intel sold them dirt cheap in the knowledge that even though they cost the same (or even slightly more) in production than the p2s of the day, they would create an artificial dichotomy and make the outrageous (then) prices of the high-end p2-400s and 450s justifiable without losing any market share (the people who would have bought the p2s if they were sensibly priced instead bought celerons.)
Yes, but is it supported as a NUMA architecture the same way the sequent stuff is? Or is it treated like an SMP?
Does GCC have PROPER 64 bit support yet, or do we wind up with a situation like the ultrasparc where the kernel gets compiled with a specially hacked version of egcs, and the userland gets compiled as 32 bit?
Indirectly, both sides (and, in fact, the whole society) would have an optimum outcome if neither side cheated. That was the whole point of the parent post, I thought.
Essentially, if both sides played fair, the outcome would be vastly preferable for both sides; but since you can't guarantee that the other side is going to, you can't afford to due to the dire consequences. Since both sides employ this reasoning, nobody has any incentive to play fair, even though everybody playing fair would be the best outcome.
OK, don't get me wrong, i'm not disagreeing with this ruling. Where do you draw the line, though?
Do you tax the providers who provide a circuit switched network, but not those who use a packet switched network? (as seems to be the case here, never mind that a lot of phone companies use ATM/AAL1 on the backhaul anyhow)
Do you tax a provider who provides you with a physical FXS connection, but not a provider who lets you make calls by some other method? (e.g. h.323 to a peering point which connects to a bunch of DS1s)
Do you only tax the incumbents, because their lines are running through public space and were paid for with public money? (this one almost makes sense)
NO! The text record was designed to insert arbitrary text strings into a zone.
That said, there's the argument that it uses _s in hostnames, which is pretty wrong (but MS do it in AD anyway,) but TXT was designed to be a generic way to add arbitrary freeform text into a zone for whatever purpose.
The 64FX is an Opteron minus one of the hypertransport channels. It's essentially the same part as an opteron 14x.
Newer 64FXs will come in an incompatible 939-pin format to prevent them being used in opteron motherboards, which is a stupid idea imho, but they're still a sledgehammer core.
Agree on the 64 non-fx, though. Totally different core with different optimisations.
No. There are plenty of legitimate configurations where the inbound MXs are not the same machines as the outbound MXs, or are different interfaces on the same machines.
This is, additionally, more elegant than the 'RMX' proposal, as 1. there could be potentially thousands of machines which were trusted to send mail from a given domain, and 2. it doesn't require a new RR type.
Slashdot Mirror
Generally in spoken english, the use of the exclusive or is indicated by prefixing the predicate with 'either'.
For instance: 'i will find either the keys to the car or the truck' implies that you will find one, but not the other. Whereas, 'i will find the keys to the car, or the keys to the truck' does not have this limitation. I imagine that most people would consider this predicate satisfied if they found that both sets of keys were hiding under the same cushion on the sofa.
Not wanting to be a pedant, but that's not the TOC. That's the first meg of the filesystem, which contains the directory structure and probably the first 900k worth of data.
The TOC is stored in the beginning of the disc in unaddressable sectors, in an area known as the PMA (Program Memory Area.) Also in this area is the ATIP and the OPC zone (on recordables.)
The TOC itself is merely a list of track/offset/length/mode/form AVPs which describe the format of the CD.
Note that in the case of multisession discs, there's more than one TOC, and more than one actual ISO filesystem. The most recent TOC is read (linked to from the original TOC), and the ISO image in this session is read. It posesses a complete filesystem structure for all the files, but the sector offsets for files in previous sessions cause the drive to seek to the previous sessions when file lookups are done.
White book kind of works this way as well.
No, no, no.
On VHS tapes, Macrovision works by exploiting the gain control circuitry (mandatory if you want to brand your player as VHS as far as I recall.)
The way it works is that there's about 30-40 scanlines above the picture (hence, not displayed on the television) which are used for signalling, subtitles, supertext, etc. Macrovision makes one or two of the pixels in this area oscillate between being really really bright, and really really dark. The AGC circuitry in the VCR compensates by either dimming or brightening the picture.
So, it's not a 'bit you set' on a VHS. On a DVD it is, and yeah, i think you have to pay some stupid organization for the 'rights' to set that bit in your encrypted content and get them to sign it, or something. On VHS, the methodology is probably still patented, but anybody COULD trivially implement it.
Bad ring pun, dude.
yes.
The Cane Toad was introduced to eat the Cane Beetle, which was causing sugar farmers great degrees of grief.
For some bizarre reason, the toad wasn't even vaguely interested in eating the grub, but did prove successful at agressively outcompeting fucktons of native species, many of which have since become extinct.
Now, the toad is apparently making inroads on kakadu.
It would be funny, however, if we introduced a virus to kill all the toads and the virus killed something else again, like people.
Then the toads would win.
Appletalk is routable, for what its worth.
A DDP address will look like two numbers separated by a dot. The first number is the 'zone' (I think, it's been a while,) which is analagous to a subnet. The second number is the endpoint address.
Ciscos support propagation of appletalk routing info via EIGRP as well as Appletalk's native protocol.
Just cos Linux won't route appletalk by default (although you can easily configure linux to do it), don't assume that appletalk isn't routable.
No. I was prepared to be open minded until that last bit.
The only reason that we still HAVE jesus' teachings, if such they are, is that ANYBODY could reproduce the New Testament (and the torah which preceeded it) for no cost. Had it been copyrighted, distribution rights would have been limited to a select oligarchy who would only have reproduced it until such time as it was no longer commercially viable.
Owing to the nature of religous texts as self-propagating viral memes, they are unlikely to get corrupted by the faithful, except during translation. The book of revelations even threatens retributions against those who modify the christian bible (and, the Qu'ran claims to be an exact copy of a book in heaven, et cetera.)
Note: I don't follow an organized religion, I'm just interested in these subjects.
It seems amusing that, despite your obvious intelligence, you've become a slavering rondroid. Get out while you can still sort of think for yourself.
You scare me.
You just described my room.
And verily did it sucketh.
I suspect the OP meant that it came 'built in' to even the low-end 'server' edition.
The ethernet PHY will be running at 10MHz, 1 bit/cycle.
The bus interface will be running at 1.79MHz (or some multiple/fraction thereof), at 8 bits in parallel.
Assuming good buffering, you could very easily saturate an 8 bit 1.79MHz bus with the output from a 10MHz serial line (which is essentially all that ethernet's PHY is.)
'cept for Gary. He rocked.
By definition, a webserver serves 'files'.
You just got out-pedanted.
Idiot.
It's unlikely it'd be a different controller. Chances are it's simply a different ram chip or two, combined possibly with a field or two in the firmware config set differently.
Admittedly, the differences are non-trivial, but the production cost for either would not vary by more than a dollar per unit, either way.
I've never had any probs with sub-10 Gig IDE disks. That said, I've had no fewer than three 30 Gig Seagate ATA66 disks collapse on me, and was burned by the 60GXP problem after I switched from Seagate to IBM as a result.
With that in mind, the only SCSI drives i've ever blown up have been the early 7200RPM Seagate Barracudas (32550 and 15150 series), which have died thermal deaths after years of constant service.
An interesting observation: These days, IDE disks seem to be built in multiples of 10GB (e.g. 10GB, 20GB, 40GB, 80GB etc) and SCSI disks come in multiples of 9GB (9, 18, 36, 72 etc.) Are they simply the same disks with a different sector sparing scheme/controller, but more reliable because they have more spare sectors? It wouldn't surprise me...
Product differentiation. No more, no less.
The same reason that Intel has been locking their multipliers since the p2-233 came out. If you make product X with fixed cost Cx, sell it for Rx, which is Cx+20%, and don't have a higher-spec product, it makes sense to introduce brain-dead product Y, which you build for the same fixed cost (Cy=Cx), but sell for Cy+20% and jack up the Rx to Cx+40 or 50%.
The WD 'special edition' drives are a good example. Several tens of dollars more for $2 worth of semiconductors.
Another good example was the Celeron 300s and 400s, most of which were capable of running at at least 450 mhz, but due to multiplier locking issues, only the 300 (which could be run at 4.5x100) was up to it. Intel sold them dirt cheap in the knowledge that even though they cost the same (or even slightly more) in production than the p2s of the day, they would create an artificial dichotomy and make the outrageous (then) prices of the high-end p2-400s and 450s justifiable without losing any market share (the people who would have bought the p2s if they were sensibly priced instead bought celerons.)
Crappy UPS.
Sun Sparcstation 4/110.
[sid@scarifier] ~$ uptime
12:19PM up 307 days, 14:34, 1 user, load averages: 0.18, 0.15, 0.10
This is far from the most impressive uptime I have seen.
Yes, but is it supported as a NUMA architecture the same way the sequent stuff is? Or is it treated like an SMP?
Does GCC have PROPER 64 bit support yet, or do we wind up with a situation like the ultrasparc where the kernel gets compiled with a specially hacked version of egcs, and the userland gets compiled as 32 bit?
Er, no.
Indirectly, both sides (and, in fact, the whole society) would have an optimum outcome if neither side cheated. That was the whole point of the parent post, I thought.
Maybe i missed something. *shrug*
Or die.....
It's called prisoner's dilemma.
Essentially, if both sides played fair, the outcome would be vastly preferable for both sides; but since you can't guarantee that the other side is going to, you can't afford to due to the dire consequences. Since both sides employ this reasoning, nobody has any incentive to play fair, even though everybody playing fair would be the best outcome.
OK, don't get me wrong, i'm not disagreeing with this ruling. Where do you draw the line, though?
Do you tax the providers who provide a circuit switched network, but not those who use a packet switched network? (as seems to be the case here, never mind that a lot of phone companies use ATM/AAL1 on the backhaul anyhow)
Do you tax a provider who provides you with a physical FXS connection, but not a provider who lets you make calls by some other method? (e.g. h.323 to a peering point which connects to a bunch of DS1s)
Do you only tax the incumbents, because their lines are running through public space and were paid for with public money? (this one almost makes sense)
Where do you draw the line?
NO!
The text record was designed to insert arbitrary text strings into a zone.
That said, there's the argument that it uses _s in hostnames, which is pretty wrong (but MS do it in AD anyway,) but TXT was designed to be a generic way to add arbitrary freeform text into a zone for whatever purpose.
No.
The 64FX is an Opteron minus one of the hypertransport channels. It's essentially the same part as an opteron 14x.
Newer 64FXs will come in an incompatible 939-pin format to prevent them being used in opteron motherboards, which is a stupid idea imho, but they're still a sledgehammer core.
Agree on the 64 non-fx, though. Totally different core with different optimisations.
No. There are plenty of legitimate configurations where the inbound MXs are not the same machines as the outbound MXs, or are different interfaces on the same machines.
This is, additionally, more elegant than the 'RMX' proposal, as 1. there could be potentially thousands of machines which were trusted to send mail from a given domain, and 2. it doesn't require a new RR type.