Yeah, that's what I was referring to when I said that it sucks. Both Linux and OSX does the same thing in the filesystem layer, so applications really don't have to care at all if a file is on WebDAV or not, and they don't need to be invoked via DAV client like explorer.
There's davfs2 for one thing. It doesn't use Fuse, as it was written before Fuse existed, so it uses Coda instead.:)
If you use Gnome, however, any Gnome program will access WebDAV for you without having to do anything particular, because of libgnome-vfs. Just browse to dav://somewhere.net/ in Nautilus (or davs:// for HTTPS). If your DAV server supports Content-Type properly, it'll open everything in the right program (if it doesn't support Content-Type, it may or may not open in the right program, but it doesn't necessarily get it wrong). I'd be surprised if KDE doesn't have something very much like it, but I don't know.
Btw., OSX has built in support for WebDAV without having to install anything. Just choose "connect to server" in Finder's menu and type in any DAV-compliant HTTP URL.
DAV client support in Windows sucks, though. I don't know -- surely Windows has to have some kind of VFS layer, so how comes Microsoft doesn't implement DAV using it instead of their current half-assed solution?
OpenOffice has DAV support for any platform, though.
5. Sharepoint. I haven't seen anything as easy to use from the FOSS community.
Honestly -- what is Sharepoint? I haven't really been touching anything Microsoft in quite some years, but I keep hearing about how good this Sharepoint stuff is. Would someone mind giving some insight?
Fighting XML is even harder than fighting the billion-dollar Microsoft FUD machine. It just isn't going to happen.
I understand your despair, but when I see threads like these, at least I understand that I'm not completely alone in my crusade against XML. I still believe that if we just continue to create domain-specific file formats and avoid other bloatfuscations in XML's likeness, it will blend out and things might work out in the end. See also here.
I really don't like the train of thought that says that "since CPUs are going multicore, multithreading is necessary". I dislike it for two reasons:
Do we really need higher performance? Seriously, I don't notice that much difference between my old AMD XP 2200+ and the newest Core2 Duo processors, because the vast majority of the time, a process doesn't even stay on it for longer than a few timeslices. Truth be told, I just now noticed that my CPU is actually running at the speed of a 1500+ because of a BIOS reset that accidentally happened some month ago. I only noticed it because I wanted to check how fast my CPU really was. Almost all performance bottlenecks are caused by I/O anyway.
Isn't that fact that you can run more processes simultaneously enough? As for me, I'd be happy enough by being able to run "make -j2" and actually having the compile go faster.
I can agree that there are a few cases where multithreading would make sense, and those would include such things as 3D rendering and multimedia encoding (although I'm not completely convinced that fork() is a perfectly acceptable solution there, too). There may be some others, too. But really, those applications are the minority. There just aren't that many CPU-bound programs these days.
People seem to argue that it would make the UI of many programs more responsive, but IMNSHO, that doesn't necessarily mean multithreading. The basic problem is that the program in question runs several coroutines, and multithreading is only one of a great many solutions to good coroutine performance, and I would argue that it is far from the best one. The problem is not that the program is actually not getting enough CPU time (except in a few cases like Firefox, but one might argue that that's a bug).
If I use the web without a mouse, I can't initiate a mouseover event [...]. What standard am I violating?
Well, call me weird or old-fashioned if you will, but I would argue that the very fact that you've used a mouseover event violates the, perhaps unwritten, convention that HTML is a "hypertext" language, not a fancy user interface specification language.
Yeah, I too think that FreeBSD is itself quite painless and very nice to work with (I use it on my laptop), but that's speaking as someone who likes Unix in all its Unixy glory. However, is there really a need for PC-BSD? If someone wants a user-friendly POSIX system, there are tons of Linux distros out there.
In my mind, the good thing with BSD is that it hasn't cared about all that, and always tried to stay Unix. If someone wants a user-friendly system, I really don't think they care whether it runs Linux or BSD underneath the shiny GUI. It's not as if they're even going to notice the difference. It seems to me that Linux generally has better support for "consumer-grade" hardware, too. I don't really get why they bother with this.
Then again, I guess it's not my time they're wasting, at least.
But doesn't anything that hurts Xandros' customers also hurt the community as you defined them?
Be that as it may, you may notice that noone has yet (to my knowledge, at least) been hurt from Microsoft's patent threats. However, the very act of Xandros and Novell signing this deal with Microsoft very much hurts the community at large. Not only does it seems to lend credence to Microsoft's claims, but even worse: It essentially enforces the Microsoft tax even on Linux sales! It means that Microsoft still get their income even when people are switching away from their products. It is also money that does not get donated to various open source developers (but instead given to what many of them would consider their worst enemy). A deal like this really is like stabbing the community in the back, in every possible way. It may (or may not, one could just as well argue) be good for Xandros' customers, but for the rest of the community (which, mind you, actually makes Xandros' product), it doesn't just lack goodness; it is really ugly.
but.. I realize that most people treat IPv6 like global warming. We all know we HAVE TO adopt it but are (as harmoniously as possible) ALL putting it off until we have no choice.
I sure don't treat it like global warming. I set up IPv6 on my network (with 6to4 global routing) quite some time ago, and it has been heaven all since I did the same with the networks of a couple of friends with whose computers I often interact, not to mention the fact that my university also runs IPv6 on most of its network. I'm able to directly communicate between any pair of computers without having to deal with NAT and port forwarding and what not. That's actually one reason I have been looking forward to the world adopting Vista -- if everyone gets an IPv6 implementation, then maybe ISPs will start rolling out native support as well.
Someone else who doesn't treat IPv6 like global warming is China. Say what you will about China and its policy towards the Internet, but they are planning a large scale IPv6 rollout (since they have like one IPv4 address per ten citizens or so). Maybe when the only way to communicate with China is over IPv6, the rest of the world might get their collective asses off the ground as well.
I'm glad that opinion hit the first post, because it was my first reaction after reading the summary as well -- "Wow, lot's of new features. So, what about the bloat?"
On my system, Firefox is easily the most memory-hungry process. I actually have to restart it every few days to make it stop eating all my RAM (although as of a few upgrade ago, it seems to be taking care of the shutting down automatically...:/). The one reason I'm using Firefox is thanks to the plugins (in this case, SessionSaver is extra good), but even so, I've been thinking quite seriously about switching to Opera instead. Free Software enthusiast as I may be, I do value technical merits as well, and Opera does seem to be doing very well (or at least a lot better) on that point.
I realize that it probably isn't all that easy to write a good web browser, but I also cannot help thinking that the fact that the entire UI is written in XML and JavaScript doesn't exactly help. I have been thinking very seriously about starting to write my own web browser (I can't really say I care if many websites don't look correctly), but I've been running into stumbling blocks when it comes to the documentation of certain web standards. In particular, I cannot find any exact specification of exactly how things such as CSS "float"ing elements are supposed to be treated (as far as I've been able to see, the CSS specification just says that they are "taken out of the flow", whatever that means). If someone can point me to reliable documentation on that, I'd be really happy.
For those who don't get the "boiling oceans" part of this joke, it is a reference to a quote by one of the ZFS developers from Sun. I don't remember the exact words off the top of my head, but the message was that "since a 128-bit file system (such as ZFS) cannot be filled by earth-based storage, you can't reach the limits of ZFS without boiling the oceans". I can't say I'm perfectly convinced of its truth value, but I'll leave that aside. I thought the joke was rather funny, at least.
Of course, that's why noone who has any kind of clue looks at such a metric as "total RAM usage", but rather at what amount of memory is allocated to block device caches and anonymous memory. Block devices caches is what you are speaking of -- caching hard drive blocks in RAM, so that they can be quickly re-accessed without having to reread them has been in every operating system since the 60's (the original UNICS also had a block cache).
Anonymous memory, on the other hand, is a much more relevant metric. That's the amount of memory processes have malloced and are currently sitting in physical RAM, rather than on the swap device. That's the kind of memory that the kernel can't just choose to "forget" to make room for new anonymous memory, unlike block caches. If the physical RAM is full and there are no block cache pages to evict, it has to write an anonymously allocated page to the swap device in order to get a new page. (Provided, of course, that there are free blocks on the swap device) That practice alone takes on the order of milliseconds (including head seek time), and it has to be done once for each page to be evicted.
There comes also the second relevant metric, namely the number of pages that are in "active use". It's one thing to have to evict a page of anonymous memory that's just sitting there (due to it being allocated by a mostly inactive process or being an unused part of libc's.data segment or for any other reason) -- that's OK. It's another thing if the only pages left are in active use, ie. if it is very likely that they will be used again in only a few timeslices. That just means that the owning process will have to wait for it to swap in again the next time it runs. When you're starting to get a large active set of pages, less RAM will also be available for block caches, which means more disk access for the filesystem's sake as well.
You're in big trouble if your active page set grows larger than your physical RAM size. That's what you call thrashing -- when every next time slice means that the running process will just waste it while reading its relevant pages back in from the swap device.
When people talk about that Vista takes a lot of RAM, they usually don't mean that it sucks up the block cache by prereading likely blocks into it. They mean that it uses a large active page set, for things like textures, metaprogramming data structures, and so forth. Any way you look at it, that's not a good thing. It may be argued that the advantages of using the programming frameworks that actually do increase the active page set like that outweigh the disadvantages of having to buy more RAM, but noone can argue that it would be better if they just used less memory.
Indeed, I can't think of anyone I know who regularly texts that gives the screen more than a casual glance every 5-10 keypresses.
If the tactile feedback really worked, though, they'd be looking at the screen constantly, rather than letting their eyes off the buttons only every 5-10 keypresses, no? Maybe then I'd also receive fewer SMSes with completely mistaken words that just happened to be on the same keys, as well. I can't quote any examples in English, but I think everyone knows what I mean...
I'm afraid you'll have to turn in your geek card. The word "spin" as used in that sentence isn't a verb, but a noun. It refers to a quantum mechanical property.
If you don't actually need Linux specifically, there is always the BSDs. They tend to have quite a bit more modest requirements, while still being current. Otherwise, did you try Gentoo?
I have two things to say about that particular case: 1) ZFS maintains checksums of all data, so that will at least be noticed fast and 2) just use two controller cards and mirror them -- if one fails, you'll have valid data in the other half of the mirror.
The more important question may be whether there are other, unknown sources of errors. Not many people would probably even think of a hard drive controller card failure when building a storage solution, and that's probably one of the major advantages of the more expensive vendors; they have the experience to know a lot more error sources. I'm not sure which weighs the heaviest: The enormous difference in price, or a chance to avoid a source of major errors that one would never have thought of on one's own (even if there's a 1 ppm risk of it happening)?
There's another interesting aspect here. Many (by far the most, probably) programs that use the GPL say "[...]under the terms of the GNU General Public License[...]; either version 2 of the License, or (at your option) any later version.". At whose option is that, really? Can the FSF decide that they want to sue someone for breaching v3 of the GPL, or can the receiver of the law suit choose that he wishes to use the program under v2 of the GPL and thus not be in breach?
Only if you're naive enough to introduce data structures that are available to several threads.
If you don't share data between threads, why would you want threads to begin with? If you have nothing to gain from sharing the same memory, why wouldn't you just fork instead?
It is definitely hard to justify parallel programming, even though many computers are gaining SMP capabilities. The thing isn't necessarily that it is particularly hard to write multi-threaded applications -- the thing is that it is a lot harder to write a multi-threaded program than to write a single-threaded program. Suddenly, you have to introduce locks in all shared data structures and ensure proper locking in all parts of the program. That kind of thing just adds a significant part to the complexity of a program, and it requires a lot more testing as well. Therefore, justification is definitely needed.
The real question then, is: Is it justified? To be honest, for most programs, the answer is no. Most interactive programs have a CPU-time/real-time ratio of a lot less than 1% during their lifetime (and very likely far less than 10% during normal, active use), so any difference brought by parallelizing them won't even be noticed. Other programs, like compilers, don't need to be parallelized, since you can just run "make -j8" to use all of your 8 cores at once. I would also believe that there are indeed certain programs that are rather hard to parallelize, like games. I haven't written a game in a quite a long time now, and I don't know the advances that the industry has made as of late, but a game engine's step cycle usually involves a lot of small steps, where the execution of the next depends on the result of the previous one. You can't even coherently draw a scene before you know that the state of all game objects has been calculated in full. Not that I'm saying that it isn't parallelizable, but I would think it is, indeed, rather hard.
So where does that leave us? I, for one, don't really see a great segment of programs that really need parallelizing. There may be a few interactive programs, like movie editors, where the program logic is heavy enough for it to warrant a separate UI thread to maintain interactive responsiveness, but I'd argue that segment is rather small. A single CPU core is often fast enough not to warrant parellelizing even many CPU-heavy programs. There definitely is a category of programs that do benefit from parellelization (e.g. database engines which serve multiple clients), but they are often parellelized already. For everyone else, there just isn't incentive enough.
Re: The original hardware store experiment
on
MacGyver Physics
·
· Score: 1
No, that's not quite it. All that happens with entangled particles is that if any entangled property is observed to have a certain in one of the particles, the same value of the same property will be observed in the other particle as well. That doesn't even require a sense of simultaneity. However, all the quantum theories that I have read about which incorporate the concept of waveform collapse (which not all of them, including the many-worlds interpretation and decoherence, do) require that the waveform collapse "simultaneously" in the entire universe, and that leads to a problem in that, according to relativity, there is no universally agreeable sense of simultaneity to begin with.
Furthermore, if the waveform did indeed collapse simultaneously in the entire universe, it would (if I'm not making some mistake somewhere) indeed allow for faster-than-light communication. If you could manufacture a stream of particles whose waveforms would indicate an equal possibility of detection in two different solar systems (I can't say I'm sure, but I am under the impression that this is a possible feat), then someone in solar system A could observe the particle, thereby making it impossible for those in solar system B to observe the same particle, therefore transmitting a bit of information in no time. Entangled particles do not allow any communication to occur, since an observation in any point still looks just like any other observation, and observers of two entangled particles at two different points would still need to communicate with each other using slower-than-light means to even confirm the rather meaningless fact that they observed the same thing.
Re: The original hardware store experiment
on
MacGyver Physics
·
· Score: 1
I don't really think that is true, because if it were, wouldn't that essentially mean that no waveform could ever build up thanks to "observations" made by virtual particles (or, for that matter, electromagnetical interactions with particles on the other side of the universe)? Wouldn't it also mean that any compound particle, such as a molecule, an atom or even a proton automatically couldn't have a waveform, since its constituent parts would constantly "observe" each other?
I recently read about quantum decoherence, and at least in my layman eyes, that seems like a much more probable explanation than that the waveform would actually collapse whenever an observation is made.
There also seems to be another interesting aspect of waveform collapse, which leads me to think that that entire concept is quite bogus: If the waveform actually does collapse, wouldn't it need to collapse in the entire universe in zero time? If that weren't the case, you could, potentially, be able to observe a particle at one point, which would cause waveform collapse, but then be able to observe it in another point as well, where the waveform collapse has not yet reached, which seems quite unnatural (not that quantum mechanics haven't eluded common sense previously). However, the concept of the waveform collapsing simultaneously everywhere seems even more impossible, seeing how the theory of relativity (pick your choice between special or general) doesn't have that kind of universal "now".
Re: The original hardware store experiment
on
MacGyver Physics
·
· Score: 1
If quantum decoherence is true, that ceases to be a problem. I'm really not the quantum physicist I'd like to be, but at least in my eyes, decoherence does seem to be a very appealing framework for explaining the waveform collapse.
Slashdot Mirror
Yeah, that's what I was referring to when I said that it sucks. Both Linux and OSX does the same thing in the filesystem layer, so applications really don't have to care at all if a file is on WebDAV or not, and they don't need to be invoked via DAV client like explorer.
If you use Gnome, however, any Gnome program will access WebDAV for you without having to do anything particular, because of libgnome-vfs. Just browse to dav://somewhere.net/ in Nautilus (or davs:// for HTTPS). If your DAV server supports Content-Type properly, it'll open everything in the right program (if it doesn't support Content-Type, it may or may not open in the right program, but it doesn't necessarily get it wrong). I'd be surprised if KDE doesn't have something very much like it, but I don't know.
Btw., OSX has built in support for WebDAV without having to install anything. Just choose "connect to server" in Finder's menu and type in any DAV-compliant HTTP URL.
DAV client support in Windows sucks, though. I don't know -- surely Windows has to have some kind of VFS layer, so how comes Microsoft doesn't implement DAV using it instead of their current half-assed solution?
OpenOffice has DAV support for any platform, though.
- Do we really need higher performance? Seriously, I don't notice that much difference between my old AMD XP 2200+ and the newest Core2 Duo processors, because the vast majority of the time, a process doesn't even stay on it for longer than a few timeslices. Truth be told, I just now noticed that my CPU is actually running at the speed of a 1500+ because of a BIOS reset that accidentally happened some month ago. I only noticed it because I wanted to check how fast my CPU really was. Almost all performance bottlenecks are caused by I/O anyway.
- Isn't that fact that you can run more processes simultaneously enough? As for me, I'd be happy enough by being able to run "make -j2" and actually having the compile go faster.
I can agree that there are a few cases where multithreading would make sense, and those would include such things as 3D rendering and multimedia encoding (although I'm not completely convinced that fork() is a perfectly acceptable solution there, too). There may be some others, too. But really, those applications are the minority. There just aren't that many CPU-bound programs these days.People seem to argue that it would make the UI of many programs more responsive, but IMNSHO, that doesn't necessarily mean multithreading. The basic problem is that the program in question runs several coroutines, and multithreading is only one of a great many solutions to good coroutine performance, and I would argue that it is far from the best one. The problem is not that the program is actually not getting enough CPU time (except in a few cases like Firefox, but one might argue that that's a bug).
In my mind, the good thing with BSD is that it hasn't cared about all that, and always tried to stay Unix. If someone wants a user-friendly system, I really don't think they care whether it runs Linux or BSD underneath the shiny GUI. It's not as if they're even going to notice the difference. It seems to me that Linux generally has better support for "consumer-grade" hardware, too. I don't really get why they bother with this.
Then again, I guess it's not my time they're wasting, at least.
Someone else who doesn't treat IPv6 like global warming is China. Say what you will about China and its policy towards the Internet, but they are planning a large scale IPv6 rollout (since they have like one IPv4 address per ten citizens or so). Maybe when the only way to communicate with China is over IPv6, the rest of the world might get their collective asses off the ground as well.
On my system, Firefox is easily the most memory-hungry process. I actually have to restart it every few days to make it stop eating all my RAM (although as of a few upgrade ago, it seems to be taking care of the shutting down automatically... :/). The one reason I'm using Firefox is thanks to the plugins (in this case, SessionSaver is extra good), but even so, I've been thinking quite seriously about switching to Opera instead. Free Software enthusiast as I may be, I do value technical merits as well, and Opera does seem to be doing very well (or at least a lot better) on that point.
I realize that it probably isn't all that easy to write a good web browser, but I also cannot help thinking that the fact that the entire UI is written in XML and JavaScript doesn't exactly help. I have been thinking very seriously about starting to write my own web browser (I can't really say I care if many websites don't look correctly), but I've been running into stumbling blocks when it comes to the documentation of certain web standards. In particular, I cannot find any exact specification of exactly how things such as CSS "float"ing elements are supposed to be treated (as far as I've been able to see, the CSS specification just says that they are "taken out of the flow", whatever that means). If someone can point me to reliable documentation on that, I'd be really happy.
For those who don't get the "boiling oceans" part of this joke, it is a reference to a quote by one of the ZFS developers from Sun. I don't remember the exact words off the top of my head, but the message was that "since a 128-bit file system (such as ZFS) cannot be filled by earth-based storage, you can't reach the limits of ZFS without boiling the oceans". I can't say I'm perfectly convinced of its truth value, but I'll leave that aside. I thought the joke was rather funny, at least.
Anonymous memory, on the other hand, is a much more relevant metric. That's the amount of memory processes have malloced and are currently sitting in physical RAM, rather than on the swap device. That's the kind of memory that the kernel can't just choose to "forget" to make room for new anonymous memory, unlike block caches. If the physical RAM is full and there are no block cache pages to evict, it has to write an anonymously allocated page to the swap device in order to get a new page. (Provided, of course, that there are free blocks on the swap device) That practice alone takes on the order of milliseconds (including head seek time), and it has to be done once for each page to be evicted.
There comes also the second relevant metric, namely the number of pages that are in "active use". It's one thing to have to evict a page of anonymous memory that's just sitting there (due to it being allocated by a mostly inactive process or being an unused part of libc's .data segment or for any other reason) -- that's OK. It's another thing if the only pages left are in active use, ie. if it is very likely that they will be used again in only a few timeslices. That just means that the owning process will have to wait for it to swap in again the next time it runs. When you're starting to get a large active set of pages, less RAM will also be available for block caches, which means more disk access for the filesystem's sake as well.
You're in big trouble if your active page set grows larger than your physical RAM size. That's what you call thrashing -- when every next time slice means that the running process will just waste it while reading its relevant pages back in from the swap device.
When people talk about that Vista takes a lot of RAM, they usually don't mean that it sucks up the block cache by prereading likely blocks into it. They mean that it uses a large active page set, for things like textures, metaprogramming data structures, and so forth. Any way you look at it, that's not a good thing. It may be argued that the advantages of using the programming frameworks that actually do increase the active page set like that outweigh the disadvantages of having to buy more RAM, but noone can argue that it would be better if they just used less memory.
I'm afraid you'll have to turn in your geek card. The word "spin" as used in that sentence isn't a verb, but a noun. It refers to a quantum mechanical property.
If you don't actually need Linux specifically, there is always the BSDs. They tend to have quite a bit more modest requirements, while still being current. Otherwise, did you try Gentoo?
The more important question may be whether there are other, unknown sources of errors. Not many people would probably even think of a hard drive controller card failure when building a storage solution, and that's probably one of the major advantages of the more expensive vendors; they have the experience to know a lot more error sources. I'm not sure which weighs the heaviest: The enormous difference in price, or a chance to avoid a source of major errors that one would never have thought of on one's own (even if there's a 1 ppm risk of it happening)?
There's another interesting aspect here. Many (by far the most, probably) programs that use the GPL say "[...]under the terms of the GNU General Public License[...]; either version 2 of the License, or (at your option) any later version.". At whose option is that, really? Can the FSF decide that they want to sue someone for breaching v3 of the GPL, or can the receiver of the law suit choose that he wishes to use the program under v2 of the GPL and thus not be in breach?
The real question then, is: Is it justified? To be honest, for most programs, the answer is no. Most interactive programs have a CPU-time/real-time ratio of a lot less than 1% during their lifetime (and very likely far less than 10% during normal, active use), so any difference brought by parallelizing them won't even be noticed. Other programs, like compilers, don't need to be parallelized, since you can just run "make -j8" to use all of your 8 cores at once. I would also believe that there are indeed certain programs that are rather hard to parallelize, like games. I haven't written a game in a quite a long time now, and I don't know the advances that the industry has made as of late, but a game engine's step cycle usually involves a lot of small steps, where the execution of the next depends on the result of the previous one. You can't even coherently draw a scene before you know that the state of all game objects has been calculated in full. Not that I'm saying that it isn't parallelizable, but I would think it is, indeed, rather hard.
So where does that leave us? I, for one, don't really see a great segment of programs that really need parallelizing. There may be a few interactive programs, like movie editors, where the program logic is heavy enough for it to warrant a separate UI thread to maintain interactive responsiveness, but I'd argue that segment is rather small. A single CPU core is often fast enough not to warrant parellelizing even many CPU-heavy programs. There definitely is a category of programs that do benefit from parellelization (e.g. database engines which serve multiple clients), but they are often parellelized already. For everyone else, there just isn't incentive enough.
Furthermore, if the waveform did indeed collapse simultaneously in the entire universe, it would (if I'm not making some mistake somewhere) indeed allow for faster-than-light communication. If you could manufacture a stream of particles whose waveforms would indicate an equal possibility of detection in two different solar systems (I can't say I'm sure, but I am under the impression that this is a possible feat), then someone in solar system A could observe the particle, thereby making it impossible for those in solar system B to observe the same particle, therefore transmitting a bit of information in no time. Entangled particles do not allow any communication to occur, since an observation in any point still looks just like any other observation, and observers of two entangled particles at two different points would still need to communicate with each other using slower-than-light means to even confirm the rather meaningless fact that they observed the same thing.
I recently read about quantum decoherence, and at least in my layman eyes, that seems like a much more probable explanation than that the waveform would actually collapse whenever an observation is made.
There also seems to be another interesting aspect of waveform collapse, which leads me to think that that entire concept is quite bogus: If the waveform actually does collapse, wouldn't it need to collapse in the entire universe in zero time? If that weren't the case, you could, potentially, be able to observe a particle at one point, which would cause waveform collapse, but then be able to observe it in another point as well, where the waveform collapse has not yet reached, which seems quite unnatural (not that quantum mechanics haven't eluded common sense previously). However, the concept of the waveform collapsing simultaneously everywhere seems even more impossible, seeing how the theory of relativity (pick your choice between special or general) doesn't have that kind of universal "now".
If quantum decoherence is true, that ceases to be a problem. I'm really not the quantum physicist I'd like to be, but at least in my eyes, decoherence does seem to be a very appealing framework for explaining the waveform collapse.