Infinite != All

Just a minor rant this time, but it's something that has been bugging me for a long time, and that I encounter quite often these days, as more and more speculation flies about the so-called "multiverse". Almost everyone who writes about the multiverse or about any infinite system, including scientists who should know better, falls prey to the same misconception about infinity... They equate infinite to all. That is, they invariably say something like, 'and thus, being infinite, every possible variation of the system must exist'. WRONG! You can have an infinite number of zeroes, in which infinite set not a single other number is ever found. You could conceivably have an infinite number of Mazda Miatas, in which not a single vehicle of any other make or manufacturer is to be found. You could have an infinite number of universes in which, due to metaphysical* constraints we don't yet understand, the fine structure constant only ever took on a single value, or two specific values, or N values, or... Yes, it could conceivably take on all possible values, but that's just one possible form of an infinite set of universes. Without theory or data to suggest a probability distribution function for whatever variable one is considering there is no possible way a priori to say how many or which values of that variable will be obtained in even an infinite number of examples of that variable. Infinite != All.

* By "metaphysical" I mean literally meta-physical, as in laws that apply to the physics of all universes in a multiverse; I do not mean supernatural.

It's orthogonal, dammit!

Alternate Title:  It's a point, dammit!

Also from the realm of physics ruminations that won't leave me alone...

Why do physicists consider higher-order (beyond our standard three) dimensions to be "rolled up" into a small space within the existing three dimensions?  They even spend a lot of time working out just how small this space must be given various theoretical and experimental results.  Yet if these additional dimensions are anything like the dimensions we know and love, I don't think there's any reason to think of them this way.  If they are orthogonal to the existing three dimensions, just extending in a direction we happen to be unable to perceive, then they needn't have any size at all in our existing set of dimensions.

I mean, if you look at a two-dimensional painting and then examine a line extending out of the plane of the painting into the third dimension, does it make any sense to think of that third dimension as somehow rolled up into the two dimensions of the painting?  No, it doesn't.  The third dimension is orthogonal to the other two dimensions.  It's kind of what orthogonal means--the new dimension does not align with the other two.  There is no overlap between the new and old dimensions.  Similarly, if the fourth spatial dimension is orthogonal to the first three, then I think it makes precisely as much sense to discuss its size in those original three dimensions as it actually takes up in those dimensions:  None at all.

I'm determined it's deterministic (maybe)

Okay, here's a silly but profound rant, just to get it out of my head.  Seeing as how it has been rattling around in there in one form or another for over two decades now, maybe this will satisfy the internal monologuist and reduce the noise level a bit.

Though I don't think I'd claim to have strong convictions about any particular interpretation of physical reality, the idea that it is potentially deterministic has long been attractive to me for some reason.  The idea that there might actually be some pervasive order underlying the apparent chaos just appeals to me.

Then quantum phenomena and Bell's inequality come along and mess things up, with most people interpreting these as implying that god does play with dice, and that no hidden variables--no underlying deterministic set of rules--can account for easily observable quantum effects.  Certainly, experimental evidence of nonlocality has been with us since Aspect's experiments in the 1980s, which have been reproduced (at greater distance) a number of times since.

But Bell's theorem only places limits on correlation for local hidden variables.  Basically, the "local realism" that entangled particles violate is predicated on purely local hidden variables.  Given the demonstrated nonlocality of quantum entanglement and the substantial number of additional dimensions posited by some modern theories of physics (11 in M-theory), the idea of non-local hidden variables doesn't seem all that far-fetched.

Granted, nonlocality is normally thought of as contrary to hidden variables and determinism.  But if there are actually more dimensions than 4 (3 space plus time), then two points that are nonlocal in our limited view of space-time may very well be local in a higher-dimensional space-time.  And hidden variables may themselves operate in a non-local fashion.  Problem solved.  Reality can be deterministic, as long as it can be described using both local and non-local variables.

The non-local hidden variables may emerge from a dimensionality greater than 4 or they may be intrinsically non-local, independent of the number of physical dimensions.  All that is required is that they appear to operate in a non-local fashion from our 4-D view of space-time.  This kind of non-locality satisfies Bell's inequality without abandoning determinism.  (In fact, if the hidden variables are actually local in those higher dimensions, it might relax the inequality completely.)  It also resolves the Einstein-Podolsky-Rosen paradox, making Einstein happy on the determinism front, though probably not on the non-locality front (anything having an effect faster than the speed of light was verboten).

Et voila, a deterministic universe.

Disclaimer:  I am not a physicist, but I do look like one:   :)

NewerTech / Vantec GUID problem solved

Okay, it turns out that NewerTech just left one tiny, but significant little tidbit out of their instructions for fixing the non-unique GUID problems with their Voyager Q drive docks (see this post).  You have to manually change the GUID yourself.  Problem solved.  So you can follow their instructions (except be sure not to have a Windows-formatted disk mounted when you do it—see this post) all the way up until they tell you to "select exit".  Before exiting, you should do the following.  (You might have to rescan the USB bus before doing this; I don't know because I never did this all in one setting.)

• Click "Modify Configuration Information"
• Change "Chip ID Lo" from 45647 to numbers of your choosing
• Click "Upload Changes"

I chose to change a couple of digits in the first part of the number, set the lowest digit to zero on the first unit I flashed, and then increment it by one for each additional unit.  It doesn't really matter what you do as long as you never use two units with the same number.

I probably should have thought of this on my own, but a helpful person at NewerTech technical support asked, as his very first question once I'd explained how my update had succeeded but failed to fix the problem, "Did you change the GUID?"  I mentioned they probably ought to add this step to their instructions.

Yay!

Vantec NexStar drive dock firmware

One final tidbit (for now) on the whole drive dock, non-unique GUID debacle...

Despite the Vantec NexStar dock using an Oxford 934DSA bridge and the NewerTech Voyager dock using an Oxford 934DSB bridge (note A vs. B), applying the firmware update provided by NewerTech to the Vantech dock doesn't hurt anything.  Nor does it help.  Before I found out that the update doesn't actually work, I decided to risk bricking one of my Vantecs to see if it could be updated too (having noticed that the binary firmware image did not mention A or B), and luckily it worked.  Well, it didn't hurt anything.  The GUID remains unchanged (just as for the NewerTech dock) at 0x30E002E0454647 and trying to attach multiple docks via Firewire still fails.  Maybe if Oxford Semiconductor and NewerTech ever actually produce a fix that works, it can be applied to the Vantec units as well.  I live in hope.

Update:  See this post for the solution to the NewerTech problem, and, happily, it does work for the Vantec problem.  If you don't want to risk upgrading the Vantec's 934DSA firmware with the 934DSB firmware provided by NewerTech, you could probably change the GUID alone, using the instructions in that post.

Warning about updating firmware in NewerTech Voyager Q

In addition to the firmware update process for the NewerTech drive dock GUID problem (see previous post) needing a few extra steps (see this post), it can also brick your dock (make it completely non-functional), even if you follow their instructions precisely.  Here's how:

You must have a drive inserted in the dock when doing the firmware update, as clearly stated by their instructions. What the instructions don't tell you is that the drive must NOT be mounted on the Windows system being used for the update.

Since my drives are normally formatted HFS+ (journaled) I probably would never have known, except for my using a still unformatted, but coincidentally DOA drive, to do my initial firmware updates.  Due to some other coincidental problems using one of the docks and my having noticed that the drive I'd used previously was DOA (it wouldn't even spin up), I tried formatting a new drive FAT 32 and carrying out the same procedure on the final NewerTech dock I needed to update.  The update failed, after wiping the firmware on the dock, officially turning it into a brick.  Actually, it went into a USB upload mode and awaited firmware flashing as if from scratch.  Fortunately, I was able to find out the flash vendor, type, speed, and burst read setting from another working Voyager device, and I was able to find the appropriate config_934DSB.txt file from the data installed with the firmware uploader app, and after switching back to the damaged, non-mounting disk, I successfully flashed the device's firmware and recovered it completely.  But it was scary and I was borderline clueless when I started that process.  It may be sufficient to unmount the drive (make it "safe to remove") before flashing, but I'm not going to try it.  If you use an unformatted or HFS+ formatted disk it shouldn't be an issue.

If you find yourself with a bricked drive dock, to recover, use the same Oxsemi Uploader.exe app that caused the problem.  Click "Select Flash" and enter the following values for the NewerTech Voyager Q [Vantec NexStar NST-D100UFS values in square brackets]:

• Flash Vendor:  Silicon Storage Technology
• Flash type:  SST39xF020 - 8 bit
• Speed:  70 ns [50ns]
• Enable burst read:  on [off]

Click "OK".  Then click "Upload/Upgrade Firmware".  At the first dialog, navigate to and select the "config_934DSB.txt" file (probably in C:\Program Files\Oxford Semiconductor\Oxsemi Uploader\Data\UF934DS).  [Use the "config_934DSA.txt" file for the Vantec.]  At the next dialog, select the firmware update file, per NewerTech's original instructions.  Let the upgrade finish, and you should have a functioning drive dock again.  Then follow the instructions in this post to actually change the GUID and you've finally solved the problem that started all this.

GUID problems with NewerTech and Vantec drive docks

[Update:  There is a solution for this problem described in this post.  The firmware update is fine, but NewerTech's instructions were just a little incomplete.  I'll leave the rest of this here to document the problem and the process.]

Drive docks, a relatively new innovation, that let you slot a bare SATA disk drive into a dock that looks like a toaster and immediately begin using the drive, without need for a permanent enclosure, are popular amongst the technorati for many good reasons.  They're effortless to use, they avoid duplication of expensive enclosures, and the best of them are highly flexible, allowing you to use any of several connection types (USB, Firewire 400, Firewire 800, and e-SATA).

However, two of what should be the best of these—the NewerTech Voyager Q and the Vantec NexStar NST-D100UFS—were released with the exact same embedded GUID (0x30E002E0454647).  This GUID needs to be unique for each device, or else both Macintosh and Windows machines will barf as soon as two of them are connected.  The problem with the NewerTech docks was noticed and diagnosed as resulting from the non-unique GUIDs over on hivelogic.  I discovered the same GUID lurking in the Vantec docks.  NewerTech / MacSales.com / Other World Computing responded on hivelogic with an announcement of a firmware update that would fix the problem.  I contacted custserv@macsales.com, per their instructions, downloaded the firmware updater at the URL they provided, had to use a Windows box to do the update (Grrrr!), only to discover that the update doesn't help in the least.

The update doesn't seem to hurt the drive dock, but it doesn't change the GUID and it doesn't allow two units to be attached to the same computer by Firewire, either in parallel or daisy-chained.  The email I received from MacSales Customer Service with the link to the update stated that "it will assign a unique ID to each unit".  But it doesn't.   I followed the instructions carefully.  The firmware uploader tool reported success.  Scanning the unit a second time reports V1_20 instead of V1_10.  Attaching it to a Mac, System Profiler reports 0x120 instead of 0x110.  It's clear that the upload worked and the firmware was updated.   But the GUID is the same problematic 0x30E002E0454647 in every unit.  And the problem with instant, error-producing dismounts when attaching two units is unchanged, whether the units are attached to two different Firewire ports or they are daisy-chained into one.   (In fact, now the Mac has to be rebooted before even a single drive can be seen and mounted, after one of these conflict events; I don't believe that was the case previously.)

Unless NewerTech or Vantec provides a solution for this, my only recourse is to return the units for a refund.  Grrrr!