Harumph! Grams are a unit of mass, not of weight, and thus independant of the gravitational force exerted on it. 3 grams on Earth is 3 grams on Mars is 3 grams on Venus is 3 grams in freefall.
Not only that, but the gravity of Venus is not one tenth that of Mars, it is closer to twice that of Mars: Venus is nearly as big as Earth. (Nor is the gravity of Mars only 1/100th Earth, it's about 1/3 Earth.)
Geez. If somebody was trying to be funny, it came off as incredibly stupid.
What is surprising here is that even very slight changes to these assumptions [...] make a big difference to the predicted results.
And that's what is significant and eye-opening. When a system or relationship previously assumed to be linear is shown to be non-linear, that throws off everything -- all analyses and assumptions based on that have to be re-evaluated. It also raises the question: what other relationships have we assumed to be linear but aren't? (IOW, how much of what we thought we knew is wrong?)
Just because Linux is based on Unix, does not mean it has the stability and testing of 20 years of Unix behind it.
True enough. But unless you're running Version 7, System III or perhaps 4.0 BSD, you're not running a Unix with 20 years of testing behind it (not all of it) either.
On the other hand, while the specific implementation may not be that old, the design concepts have been around long enough to prove themselves out.
You need to watch your terminology. In the film industry, "editing" has a very specific and narrow meaning which would omit compositing software, modelling software, rendering software, animation software, and so on. In the computer business, "editing" is a pretty generic term for "changing".
Film Gimp is not (movie sense) editing software, it's image manipulation software that could be used for compositing, touch up, etc.
As for why, Linux is just a better OS for developing any kind of software;-)
For movie work, yeah, mostly SGI and IRIX. For lower end stuff (ie, made-for-TV and commercials), NT was (and still is) also pretty widely used. A lot of production software was ported to (or written for) NT when it looked to some like NT would replace Unix, and SGI flirted with NT for a while too.
That trend is starting to swing in the Linux direction -- the same commodity hardware advantage that NT offered, but with the software advantages of Unix. And a price better than either.
Think of it this way: the variable is just a (named) bucket that can hold stuff, objects are the stuff that sometimes goes in the buckets (and sometimes is just pointed to by something in a bucket, etc.)
If you put a Foo object in bucket 'bar', it will still be a Foo object when you take it out, so (in a strongly typed language) you'd better be expecting a Foo. But when you're done with the Foo, you can put a Baz object in that bucket 'bar'.
The bucket doesn't have a type, the object in the bucket does.
So you're saying that unless you work for Microsoft, you shouldn't be a programmer?
Your words, not mine. Perhaps you were just setting up a strawman to knock down with a clever (not) retort. Or perhaps you just couldn't quite comprehend what I wrote. Okay, I'll try to keep it to words of one or two syllables:
It was a mistake to try to copy MS's newest APIs and designs because they can (and will) patent that stuff and shoot you out of the water. Besides (the part of my first comment you ignored), it also makes the MS idea seem better in the eyes of users, and why settle for a late copy when you can have the real thing?
As for your other comment: MS couldn't sue over Linux because any relevant IP belonged to AT&T -- and that court fight was settled with BSD. (Besides, the one patent AT&T had on Unix, the suid bit (things were different about software patents in those days) had both been released to the public domain and expired. Copyrights didn't enter into the Linux effort the way they did with BSD, Linus never saw AT&T code.)
No. First, its basic functional capabilities have pre-existed too long to be held up by patents.
Somebody has far too much faith that the Patent Office will not issue a patent for that which has prior art. Sorry, but it doesn't look that way from here. The PTO may well grant a patent, even though it really shouldn't. Then what?
if Microsoft does patent some technology, then our plan is to [...] find prior art that would render the patent useless.
Which means a lawsuit. More specifically, it means defending against an infringment lawsuit brought by Microsoft. This is the sort of thing that the side with the deeper pockets usually wins, just because he can keep stretching things out and delaying final judgement. How deep did you say your pockets were? (We know how deep Microsoft's are.)
I've always been of the opinion that Mono was a misguided waste of development time and talent -- precisely because Microsoft could (and would) torpedo it before it became a real threat (and after it had soaked up a ton of open source developer time and "validated".NET in a lot of people's minds.) Looks like the torpedo bay doors are coming open.
Yes, and with the current state of the Patent and Trademark Office (as for the last few years), just about any patent applied for gets granted, especially if the applicant has deep pockets.
The PTO gets paid more for issuing a patent than for declining one, and the PTO is "self-funding". Furthermore, there's no penalty to the PTO if they're found to have issued a patent they shouldn't have (ie for prior art, obviousness, whatever) -- the penalty is all to those buying, er, obtaining the patent, and to the public for suffering bogus patents.
Hyperlinks are well and good -- but they shouldn't serve as a crutch for bad writing, either. A well-written man page (there are some) is a joy to behold, and stands on its own. Which would you rather have -- Microsoft hyperlinked "help" or a plain text readable-from-the-command-line man page?
As far as paper editions go -- paper is easier on the eyes, more portable, more durable (spilling coffee on your books is annoying, but beats heck out of spilling coffee on your laptop) and easier to make notations on.
Besides which, the CO2 absorbed by that tree gets retained in the paper for as long as it lasts. Do your bit to prevent global warming, use paper documentation!
(And all that said, I have a couple of the O'Reilly "library on a CD" discs -- all HTML-ized -- mounted on my internal server so I can refer to them instantly.)
they do not have a tutorial style, and generally show you the commands and a brief definition
Uh, that's all they (man pages) are supposed to have. Back in the dawn of time, or at least of Unix, the documentation consisted of two "volumes" (several inches thick each if you printed it all out on looseleaf paper to put in a binder). Volume 1 consisted of man pages, with the different sections being numbered as we know the numbering today. Volume 2 -- rarely seen anymore -- consisted of white papers, users guides and other detailed documentation for the commands that weren't obvious from the man page. (For example, cp only needs a man page, even with all the bells and whistles added since the early days. Something like troff or yacc needs a bit more -- and you'd find that bit more in Volume 2.)
Online documentation (speaking in general here) is great (searchable, hyperlinks, etc) when you're looking for something specific. Paper documentation is wonderful when you just want to browse (in the old fashioned sense) to discover stuff you didn't know you needed -- especially if you want to do that in places where a computer isn't convenient.
The seek times alone within these files must be huge,
Depends on how your inodes are laid out, how big you have to get for triple indirect blocks, etc.
Shouldn't be any worse (and maybe better) than trying to seek through an equivalent collection of smaller files -- you've got to do all those directory searches, etc. (Exact comparisons will depend greatly on the filesystem and parameters chosen when the FS was created.)
Can anyone give a good reason for needing files larger than 2gb?
Video/movie files, for one thing. Even compressed (eg DV or MPEG) those things are huge. A 2 GB file at professional DV compression (50 Mb/sec) is about 4 minutes worth. (DV is similar to MJPEG, so it's still lossy. Uncompressed or unlossy compressed video (critical for machine vision or image analysis apps) chews even more space.
I know I've wanted to be able to just dump a mini-DV tape (about 13 GB) directly to a single disk file for later editing.
Other fields also use huge data sets - seismic data analysis for example. Filesystems designed for supercomputer clusters (eg PVFS) have unlimited size on the total filesystem (tens of terabytes is not unusual) although the individual file size may still be limited by the underlying OS or hardware word size.
Then there's creating a.zip or.tgz of a collection of big files. Or creating the equivalant of an ISO image of a DVD. And so on.
Ah, the sweet ignorance of youth...
on
Copyright Rumblings
·
· Score: 4, Informative
when it comes to rolling stones i think some of their oldest stuff is whats still defining them, but i dont know if they go back 28 years
Um, dude, this year the Stones are celebrating their 40th anniversary as a band. They've released a 40-track double-CD collection called "40 Licks" in honour of the occasion.
you'll see a lot of copyright postings that point back to Unix Systems Laboratories
Meaning nothing. If you grep through the source (even/usr/include/*) of commercial Unices, you'll see copyright notices in there from everyone and his dog, including Microsoft (old Xenix stuff). Some files have a dozen different copyright statments in there -- as each contributer added his stuff, but under whatever existing licence that code was under.
Heck, I just did
"grep -r -i microsoft/usr/include/*|grep copyright" on my linux box and it turned up a whole bunch of stuff in the Xm (Motif) headers that was copyright 1988 by Microsoft -- and other dates by MIT, DEC, HP, Open Group, OSF, etc....
Wonder how much of that sort of crap is in SCO Unlinx or whatever they're calling it this week.
The standard C++ grammar is highly ambiguous. So not even infinite lookahead can be used to parse it.
I figure that, after a reasonable attempt to figure it out from context, the compiler should be free to throw up its hands in disgust and tell the programmer something like: "I can't figure out what the hell you mean here, and if I can't, probably a human couldn't either. Please make it less ambiguous."
As the various obfuscated C (etc) programming contests prove, just because code is syntactically (and semantically) legal doesn't mean it's comprehensible.
infinite lookahead is still required. Actually only very few problems are solved with finite (aka k) lookahead.
Not to worry. If it can't be solved with finite lookahead, the program source itself must be infinite (or incorrect), and the compiler will never halt anyway.
Determining ahead of time whether this is the case is left as an exercise for the student;-)
most of whom don't understand how the microwave works
Including, apparently, the poster.
The microwave oven beam is directional only until it hits the "stirrer", a rotating paddle designed to spread the microwaves all over the interior of the oven (for even heating). Plenty will leak out the front if it isn't shielded.
The screen does a wonderful job at stopping the (microwave) radiation, since the holes are far smaller than the wavelength -- it "looks" like solid metal to the microwaves.
As for the energy -- there may be higher total wattage in the microwave beam, but per-photon the higher-frequency light waves have much higher energy. That higher frequency also means the wavelength is small enough to easily pass through the holes in the screen, so you can watch your dinner cooking, or the pretty light show from nuking an AOL CD.
How does the power supply know if it needs to juice up it's neighbor?
That information is supposed to be reported by each device in a Self-ID packet it sends out when attached to the bus (or when there's a bus reset). That packet includes info about whether it's a source or sink of power and approximately (ie within what category) how much.
(Note there's a wide range of allowable voltage on the power lines: 8v to 33v (the older spec went up to 40v))
DV manufacturers decided in their infinite wisdom to make it so you could only capture in one format (DV)?
Um, what would you expect a DV manufacturer to make?
will I be able to software compress a DV stream as I capture it?
A DV stream is already digital, you don't need to "capture" it. And it's already compressed (it's similar to MJPEG). And there are actually two DV formats (well, more than that if you count NTSC vs PAL), 25 Mb/sec (the usual) and higher quality 50 Mb/sec used in high end professional gear.
Oh, and not all Firewire video is DV. There are some applications (notably machine vision) where you don't want any compression artifacts, so you run an uncompressed data stream over the wire. Requires specialized gear.
my question to the 1394b creators
All of which has nothing to do with 1394b. DV over 1394a only uses 100 Mb/sec of bandwidth, and a lot of that is empty packets (the main constraint is the timing, if you're sending real-time video you use an isochronous channel on the firewire). 1394b probably (I haven't looked at that part of the spec) means you can run more isochronous channels at the same time, for simultaneous real-time video streams, but I don't know for sure. Either way the DV format doesn't change.
You know what sucks about firewire?
All the devices are powered.
That turns out not to be the case.
Look at the "mini" Firewire connector on digital camcorders (and some laptops). (On Sony products it'll be called "i.Link", their name for 1394). It only has 4 pins -- no power pins. The camera isn't going to try to power anything nor accept power from anything.
Can't say as I've tried connecting 20 FW drives to a G4, but I have connected a whole mess of A/V gear, computers and drives together with Firewire with no problems.
The 1394a spec calls for current limiting and protection diodes on all ports of a power-providing device (NB, not all self-powered devices necessarily provide power to the bus, eg the camcorders above), but the older 1394-1995 spec only called for a single diode for all ports (ie closer to the power supply). (That spec described different power limits.) Maybe your G4 (or the drives) ports weren't up to the 1394a spec.
The 1394b spec actually calls for speeds up to 3200 Mb/sec, being an 8x improvment over the 1394a spec (800, 1600 and 3200 vs 100, 200 and 400). The spec also calls for cable lengths up to 50 meters over plastic fibre, as I recall.
The current Apple implementation may be a price/performance trade-off.
Slashdot Mirror
[3 grams (Earth-terran), 0.03 grams (Mars), 0.003 grams (Venus)]
Harumph! Grams are a unit of mass, not of weight, and thus independant of the gravitational force exerted on it. 3 grams on Earth is 3 grams on Mars is 3 grams on Venus is 3 grams in freefall.
Not only that, but the gravity of Venus is not one tenth that of Mars, it is closer to twice that of Mars: Venus is nearly as big as Earth. (Nor is the gravity of Mars only 1/100th Earth, it's about 1/3 Earth.)
Geez. If somebody was trying to be funny, it came off as incredibly stupid.
Nissan was always the auto company's name in Japan. Datsun was a (temporary) North American thing.
Not necessarily. Both Mc and Mac are used in Scottish names. I vaguely recall that it might be a highland/lowland thing, but I wouldn't swear to it.
On my mother's side I come from a long line of "Mc"s, not "Mac"s.
What is surprising here is that even very slight changes to these assumptions [...] make a big difference to the predicted results.
And that's what is significant and eye-opening. When a system or relationship previously assumed to be linear is shown to be non-linear, that throws off everything -- all analyses and assumptions based on that have to be re-evaluated. It also raises the question: what other relationships have we assumed to be linear but aren't? (IOW, how much of what we thought we knew is wrong?)
Just because Linux is based on Unix, does not mean it has the stability and testing of 20 years of Unix behind it.
True enough. But unless you're running Version 7, System III or perhaps 4.0 BSD, you're not running a Unix with 20 years of testing behind it (not all of it) either.
On the other hand, while the specific implementation may not be that old, the design concepts have been around long enough to prove themselves out.
for developing film editing software
;-)
You need to watch your terminology. In the film industry, "editing" has a very specific and narrow meaning which would omit compositing software, modelling software, rendering software, animation software, and so on. In the computer business, "editing" is a pretty generic term for "changing".
Film Gimp is not (movie sense) editing software, it's image manipulation software that could be used for compositing, touch up, etc.
As for why, Linux is just a better OS for developing any kind of software
For movie work, yeah, mostly SGI and IRIX. For lower end stuff (ie, made-for-TV and commercials), NT was (and still is) also pretty widely used. A lot of production software was ported to (or written for) NT when it looked to some like NT would replace Unix, and SGI flirted with NT for a while too.
That trend is starting to swing in the Linux direction -- the same commodity hardware advantage that NT offered, but with the software advantages of Unix. And a price better than either.
At this stage as a research project it's a tool that doesn't need to paid in cash.
Why do I suspect that by the time Microsoft management gets through with it, it will be payable in cash only, and to you know who.
Want to send email to anyone to or from MSN, Hotmail, or any other MS-owned domain? Sure thing -- is your license of Microsoft Postage paid up?
Think of it this way: the variable is just a (named) bucket that can hold stuff, objects are the stuff that sometimes goes in the buckets (and sometimes is just pointed to by something in a bucket, etc.)
If you put a Foo object in bucket 'bar', it will still be a Foo object when you take it out, so (in a strongly typed language) you'd better be expecting a Foo. But when you're done with the Foo, you can put a Baz object in that bucket 'bar'.
The bucket doesn't have a type, the object in the bucket does.
So you're saying that unless you work for Microsoft, you shouldn't be a programmer?
Your words, not mine. Perhaps you were just setting up a strawman to knock down with a clever (not) retort. Or perhaps you just couldn't quite comprehend what I wrote. Okay, I'll try to keep it to words of one or two syllables:
It was a mistake to try to copy MS's newest APIs and designs because they can (and will) patent that stuff and shoot you out of the water. Besides (the part of my first comment you ignored), it also makes the MS idea seem better in the eyes of users, and why settle for a late copy when you can have the real thing?
As for your other comment: MS couldn't sue over Linux because any relevant IP belonged to AT&T -- and that court fight was settled with BSD. (Besides, the one patent AT&T had on Unix, the suid bit (things were different about software patents in those days) had both been released to the public domain and expired. Copyrights didn't enter into the Linux effort the way they did with BSD, Linus never saw AT&T code.)
No. First, its basic functional capabilities have pre-existed too long to be held up by patents.
.NET in a lot of people's minds.) Looks like the torpedo bay doors are coming open.
Somebody has far too much faith that the Patent Office will not issue a patent for that which has prior art. Sorry, but it doesn't look that way from here. The PTO may well grant a patent, even though it really shouldn't. Then what?
if Microsoft does patent some technology, then our plan is to [...] find prior art that would render the patent useless.
Which means a lawsuit. More specifically, it means defending against an infringment lawsuit brought by Microsoft. This is the sort of thing that the side with the deeper pockets usually wins, just because he can keep stretching things out and delaying final judgement. How deep did you say your pockets were? (We know how deep Microsoft's are.)
I've always been of the opinion that Mono was a misguided waste of development time and talent -- precisely because Microsoft could (and would) torpedo it before it became a real threat (and after it had soaked up a ton of open source developer time and "validated"
Microsoft have applied for a patent,
Yes, and with the current state of the Patent and Trademark Office (as for the last few years), just about any patent applied for gets granted, especially if the applicant has deep pockets.
The PTO gets paid more for issuing a patent than for declining one, and the PTO is "self-funding". Furthermore, there's no penalty to the PTO if they're found to have issued a patent they shouldn't have (ie for prior art, obviousness, whatever) -- the penalty is all to those buying, er, obtaining the patent, and to the public for suffering bogus patents.
Hyperlinks are well and good -- but they shouldn't serve as a crutch for bad writing, either. A well-written man page (there are some) is a joy to behold, and stands on its own. Which would you rather have -- Microsoft hyperlinked "help" or a plain text readable-from-the-command-line man page?
As far as paper editions go -- paper is easier on the eyes, more portable, more durable (spilling coffee on your books is annoying, but beats heck out of spilling coffee on your laptop) and easier to make notations on.
Besides which, the CO2 absorbed by that tree gets retained in the paper for as long as it lasts. Do your bit to prevent global warming, use paper documentation!
(And all that said, I have a couple of the O'Reilly "library on a CD" discs -- all HTML-ized -- mounted on my internal server so I can refer to them instantly.)
they do not have a tutorial style, and generally show you the commands and a brief definition
Uh, that's all they (man pages) are supposed to have. Back in the dawn of time, or at least of Unix, the documentation consisted of two "volumes" (several inches thick each if you printed it all out on looseleaf paper to put in a binder). Volume 1 consisted of man pages, with the different sections being numbered as we know the numbering today. Volume 2 -- rarely seen anymore -- consisted of white papers, users guides and other detailed documentation for the commands that weren't obvious from the man page. (For example, cp only needs a man page, even with all the bells and whistles added since the early days. Something like troff or yacc needs a bit more -- and you'd find that bit more in Volume 2.)
Online documentation (speaking in general here) is great (searchable, hyperlinks, etc) when you're looking for something specific. Paper documentation is wonderful when you just want to browse (in the old fashioned sense) to discover stuff you didn't know you needed -- especially if you want to do that in places where a computer isn't convenient.
The seek times alone within these files must be huge,
Depends on how your inodes are laid out, how big you have to get for triple indirect blocks, etc.
Shouldn't be any worse (and maybe better) than trying to seek through an equivalent collection of smaller files -- you've got to do all those directory searches, etc. (Exact comparisons will depend greatly on the filesystem and parameters chosen when the FS was created.)
Can anyone give a good reason for needing files larger than 2gb?
.zip or .tgz of a collection of big files. Or creating the equivalant of an ISO image of a DVD. And so on.
Video/movie files, for one thing. Even compressed (eg DV or MPEG) those things are huge. A 2 GB file at professional DV compression (50 Mb/sec) is about 4 minutes worth. (DV is similar to MJPEG, so it's still lossy. Uncompressed or unlossy compressed video (critical for machine vision or image analysis apps) chews even more space.
I know I've wanted to be able to just dump a mini-DV tape (about 13 GB) directly to a single disk file for later editing.
Other fields also use huge data sets - seismic data analysis for example. Filesystems designed for supercomputer clusters (eg PVFS) have unlimited size on the total filesystem (tens of terabytes is not unusual) although the individual file size may still be limited by the underlying OS or hardware word size.
Then there's creating a
when it comes to rolling stones i think some of their oldest stuff is whats still defining them, but i dont know if they go back 28 years
Um, dude, this year the Stones are celebrating their 40th anniversary as a band. They've released a 40-track double-CD collection called "40 Licks" in honour of the occasion.
you'll see a lot of copyright postings that point back to Unix Systems Laboratories
/usr/include/*) of commercial Unices, you'll see copyright notices in there from everyone and his dog, including Microsoft (old Xenix stuff). Some files have a dozen different copyright statments in there -- as each contributer added his stuff, but under whatever existing licence that code was under.
/usr/include/*|grep copyright"
Meaning nothing. If you grep through the source (even
Heck, I just did
"grep -r -i microsoft
on my linux box and it turned up a whole bunch of stuff in the Xm (Motif) headers that was copyright 1988 by Microsoft -- and other dates by MIT, DEC, HP, Open Group, OSF, etc....
Wonder how much of that sort of crap is in SCO Unlinx or whatever they're calling it this week.
The standard C++ grammar is highly ambiguous. So not even infinite lookahead can be used to parse it.
;-)
I figure that, after a reasonable attempt to figure it out from context, the compiler should be free to throw up its hands in disgust and tell the programmer something like: "I can't figure out what the hell you mean here, and if I can't, probably a human couldn't either. Please make it less ambiguous."
As the various obfuscated C (etc) programming contests prove, just because code is syntactically (and semantically) legal doesn't mean it's comprehensible.
infinite lookahead is still required. Actually only very few problems are solved with finite (aka k) lookahead.
Not to worry. If it can't be solved with finite lookahead, the program source itself must be infinite (or incorrect), and the compiler will never halt anyway.
Determining ahead of time whether this is the case is left as an exercise for the student
most of whom don't understand how the microwave works
Including, apparently, the poster.
The microwave oven beam is directional only until it hits the "stirrer", a rotating paddle designed to spread the microwaves all over the interior of the oven (for even heating). Plenty will leak out the front if it isn't shielded.
The screen does a wonderful job at stopping the (microwave) radiation, since the holes are far smaller than the wavelength -- it "looks" like solid metal to the microwaves.
As for the energy -- there may be higher total wattage in the microwave beam, but per-photon the higher-frequency light waves have much higher energy. That higher frequency also means the wavelength is small enough to easily pass through the holes in the screen, so you can watch your dinner cooking, or the pretty light show from nuking an AOL CD.
How does the power supply know if it needs to juice up it's neighbor?
That information is supposed to be reported by each device in a Self-ID packet it sends out when attached to the bus (or when there's a bus reset). That packet includes info about whether it's a source or sink of power and approximately (ie within what category) how much.
(Note there's a wide range of allowable voltage on the power lines: 8v to 33v (the older spec went up to 40v))
DV manufacturers decided in their infinite wisdom to make it so you could only capture in one format (DV)?
Um, what would you expect a DV manufacturer to make?
will I be able to software compress a DV stream as I capture it?
A DV stream is already digital, you don't need to "capture" it. And it's already compressed (it's similar to MJPEG). And there are actually two DV formats (well, more than that if you count NTSC vs PAL), 25 Mb/sec (the usual) and higher quality 50 Mb/sec used in high end professional gear.
Oh, and not all Firewire video is DV. There are some applications (notably machine vision) where you don't want any compression artifacts, so you run an uncompressed data stream over the wire. Requires specialized gear.
my question to the 1394b creators
All of which has nothing to do with 1394b. DV over 1394a only uses 100 Mb/sec of bandwidth, and a lot of that is empty packets (the main constraint is the timing, if you're sending real-time video you use an isochronous channel on the firewire). 1394b probably (I haven't looked at that part of the spec) means you can run more isochronous channels at the same time, for simultaneous real-time video streams, but I don't know for sure. Either way the DV format doesn't change.
You know what sucks about firewire?
All the devices are powered.
That turns out not to be the case.
Look at the "mini" Firewire connector on digital camcorders (and some laptops). (On Sony products it'll be called "i.Link", their name for 1394). It only has 4 pins -- no power pins. The camera isn't going to try to power anything nor accept power from anything.
Can't say as I've tried connecting 20 FW drives to a G4, but I have connected a whole mess of A/V gear, computers and drives together with Firewire with no problems.
The 1394a spec calls for current limiting and protection diodes on all ports of a power-providing device (NB, not all self-powered devices necessarily provide power to the bus, eg the camcorders above), but the older 1394-1995 spec only called for a single diode for all ports (ie closer to the power supply). (That spec described different power limits.) Maybe your G4 (or the drives) ports weren't up to the 1394a spec.
The 1394b spec actually calls for speeds up to 3200 Mb/sec, being an 8x improvment over the 1394a spec (800, 1600 and 3200 vs 100, 200 and 400). The spec also calls for cable lengths up to 50 meters over plastic fibre, as I recall.
The current Apple implementation may be a price/performance trade-off.
A geiger counter in a wrist watch? Come on, James Bond had one of those in the movie Thunderball, back in the 1960s.