So for the Valve titles, even if you get the physical media, you still have to play through Steam. Essentially the only difference between buying the electronic copy and the retail version is the discs eliminate most of the download step. (E.g. if Steams servers went away, you wouldn't be able to play the game from the retail discs.)
Because in this context "free" sometimes means "freely available to use", sometimes it means "sorta freely available to use, but you need to mention us in your docs" and sometimes it means "impossible to use, due to proprietary license that may (or may not) allow you to link to this code at all".
And to be fair, sometimes it means "impossible to use, due to a copyleft license that disagrees with this other copyleft license." Hell, you can't even use GPL v2-only and GPL v3 code together, let alone something like GPL and the CPL.
Their estimated temperature was one of the things that made it look "Earth-like", and it's one of the measurements they are needing to revise that make it no-longer look Earth-like.
IMHO it's more logical to avoid such large numbers by using decimal points. Release 4.1, 4.2, 4.3 this year, not 5, 6, 7.
That's only a clear win if there's some notion of compatibility (either programmatic or user experience) that you're maintaining among the 4.x releases, and even then it may not be. E.g. I find the progression of Linux kernel versions to be increasingly ridiculous; I'd rather see "the current stable release is 37.2 and the current unstable release is 38-rc7" than "the current stable release is 2.6.37.2 and the current unstable is 2.6.38-rc7".
If you stick to the point releases when there's no discernible big jump in features or whatever in a new release, as is what Linux is doing and what Mozilla wants to do, you've just turned "Chrome and Firefox will be up to version 40-something" to "Chrome and Firefox will be up to version 4.40-something", because if there are no stand-out updates, when do you bump the major revision number?
Depends on what you mean by "lasts"; they degrade gracefully, not fail suddenly. Wikipedia and other sources say that several manufacturers warranty their panels at 80% output at 25 years. I'd consider that lasting well past 25 years.
Not according to unix.org. What you are talking about is the C99 standard which isn't about data models but a specific programming language specification.
'long long' was a common compiler extension well before C99. It was available by at least GCC 2.7.2.3, which was released Aug 1997. That's the earliest version I have access to without compiling stuff.
And to some extent you're right about the disconnect about the data model and C language -- but at the same extent, IMO they're so tightly coupled in Unix that I also think it's reasonable to talk about what was going on in the world of C.
However you would have to maintain those data structures forever instead of relying on MS data types. Or you could the very messy task of putting in #IFDEF everywhere to separate your 64-bit/32-bit parts if you wanted to use the MS data types but keep one version of source code. You could do all of that. Or you could maintain two versions. I would think it's far easier to maintain two versions.
While I'll admit that I don't have a ton of experience with coding in "the Windows way" using all their DWORD and LPVOID jazz, and I don't know exactly what effect the 64-bit switch has on them, I'm still not really seeing the problem. C provides 'intptr_t' for an address-sized integer, and Windows provides ULONG_PTR and DWORD_PTR. All of these types behave like 'long' does under Linux: it's 32-bit when compiling for a 32-bit target and 64-bit when compiling for a 64-bit target.
I was off in some fantasy world where code was actually generally well-written and didn't make architecture-specific assumptions about the size of integers.
That said, you still have a couple things wrong. First, LLP doesn't really "introduce" long long; that's been usable even in 32-bit software for ages. Second, while you do have to do some rewriting to get your code 64-bit clean if you aren't in my magical fantasy world, it's absolutely wrong to say you then need to maintain two source trees.
You make a lot of assumptions here, and I don't think that they necessarily pan out in practice.
The whole point of using Windows is backwards compatibility.
That's part of it, but it's not the whole story. For instance, I use Windows on my home box partially because I'm one of those strange people who actually like it. (Actually that's not quite true; in reality, I tend to like Linux and Windows about the same, and I dislike both. But the important thing is that Linux and Windows annoy me in different ways, and I use Linux at work, so by running Windows at home I get some variety in my frustration instead of it always being focused on one thing.)
Now I do have some Windows-only software that I use (a couple games and Adobe Lightroom), but 90% of the time I've just got stuff that has easy cross-platform replacements.
Which brings me to my next point:
Microsoft would have to use dynamic translation techniques... and any power consumption advantage that ARM may have would be more than eliminated.
But what if they only have to use those dynamic translation techniques 5% or 10% of the time? There are a lot of people whose use probably falls under that: most of the time they're using software they could get ARM versions of easily enough, or change to a slightly different program if they couldn't, and then once every few days they'd use a program that would need binary translation.
Now, does that apply to everyone? No. But I think it would apply to most people. (Look at how many people have switched to doing a lot of stuff on their iPhones and iPads.) The bigger question is how savvy you'd need to be to pick up the fact that you should and could get a new version of the software. (And here again I think it'd be reasonably easy to do that.)
Finally, who says that ARM needs to be confined to systems where battery life is important? I'm waiting with somewhat baited breath for more information about nVidia's Project Devner. Those are chips meant for desktops and servers. Will they be good enough to pick over whatever Intel and AMD have out at the time? I dunno... quite possibly not. But they may well be. And that would be very exciting.
Uh what? I'm curious what characteristics of the Windows model meant that the similar "recompile" model wouldn't work on Windows. Because I don't know of any.
Actually that's not quite true; I can think of at least one difference: if you use native C types and use a long to store a pointer value. With the typical Windows model, that would result in a truncation; with the typical Linux model, that would continue to work.
That said, that code is latently broken anyway; in some sense it doesn't deserve to work in the first place. But that doesn't mean that the Windows crew has to maintain two source trees; that's ridiculous. What it means instead is that if you have an 'int' variant that you want to hold an address, you should use 'intptr_t' instead. Which is what the Linux software should be doing anyway.
Software companies that wanted to take advantage of 64-bit for Windows had to maintain separate 32-bit and 64-bit binary and source code versions during the migration.... A 32-bit program could be made into a 64-bit program with a recompile and testing to ensure there were no special scenarios that required 32-bit addresses, etc. Software companies would have to maintain two binary versions but for the most part could maintain one version of source code.
Uh what? I'm curious what characteristics of the Windows model meant that the similar "recompile" model wouldn't work on Windows. Because I don't know of any.
I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?
XP 64 got off to a bit of a bad start, but I havn't run anything but 64-bit Windows on my home system for years; that goes back to the pre-Win 7 era (I was running 64-bit Server 2008 for a year or so).
And even the XP case is overstated, at least nowadays. Until fairly recently I was running 64-bit XP at work (I've switched to Linux); several other people in my group still are. It works fine.
I haven't, for either. That being said, I'd be extraordinarily surprised if it worked in the case of the Oregon Trail, as my understanding is that Win 7 doesn't have 16-bit support period. I'm not sure what I'd set it to for Guitar Hero; there isn't a separate "32-bit XP" option or anything, and it doesn't claim to support previous versions. You never know, it could work... but I doubt it. (I also did some searches for workarounds, which is how I found out about Orca, and didn't see anything about it.)
(Also note that I'm not the OP you were replying to, just in case that wasn't clear from my last post.)
"Those who don't understand UNIX are condemned to reinvent it, poorly."
I have my own corollary: "Those who understand Unix are condemned to invent it, well." (Read that in a somewhat insulting way and you get the idea.)
As someone who uses both Windows and Linux a lot, there's a lot to like and a lot to hate about both systems. I think Windows, especially recent versions, gets a bad rap amongst CS folks. And I think that there are a lot of things about Unix that I describe as persisting because the people who work on it refuse to acknowledge it's no longer 1975. (This is being deliberately antagonistic, and it overstates my feeling, but it does get the essence.)
For example, I've been involved in a few discussions over the years here about what a file system should look like for instance, and saying things like that I think Transactional NTFS is awesome and I wish *nixs would support it -- and I've gotten almost nearly unanimous dissent amongst Unix oldbeards. That's something MS has done right, and it's a huge pity that you can't write cross-platform software that uses a transactional file system.
This isn't to say Windows is perfect: it isn't, not by any stretch of the imagination. It's got implementation issues (buffer overflows), configuration issues (largely borne out of a desire for backwards compatibility), and what I feel it's biggest problem going forward is, which is an API that... is not very clean in many respects. (E.g. Unix's fork/exec method of process "creation" is way cleaner than CreateProcess because the latter has to take into account lots of stuff (changing the environment, remapping file descriptors, etc.) that you would do between fork and exec on Unix.)
I can sort of give you two examples, though that fail because of the 64-bitness of my Win 7 installation rather than the Windows version specifically. First is The Oregon Trail II; this is a 32-bit program but has a 16-bit installer. So the installer won't run. (You can install to, say, a VM then copy stuff over.) Second example is Guitar Hero 3. That checks for 32-bitness and (because I'm pretty sure that Aspyr produced that Windows port by taking the console code and taking a shit on it) fails if it's 64-bit. (You can edit the MSI with a program called Orca to remove that check, and then things install.)
It's not quite irrelevant to everyone because there are a lot of crappy scripts (especially written by people who run *nix) that assume that your paths don't have spaces in them.
I know that it is not a an analogue for time machine but a lot of Apple detractors try to paint Shadow copy as the same thing as time machine which it obviously isn't.
I'll back off a little bit. That being said, while the original poster mentioned Time Machine, he also talked about perhaps implementing it with something like LogFS. (For those unfamiliar with that, think of it as a COW system. Keep around the old metadata and you have access to the old versions of files.) Along with the motivation of why he wants it (a "replacement" for the trash/recycle bin), that indicates to me that what he wants is an in-filesystem solution. VSS is thus closer to being that than Time Machine is, especially from a technical point of view. Because of this, it was appropriate for your parent to bring it up VSS as being similar, and pretty irrelevant for to go complaining about it not providing disaster recovery.
AT&T supplied me with a small piece of hardware for my adsl connection. AT&T refers to it as a modem even though it doesn't modulate or demodulate anything.
Wikipedia disagrees: "Broadband modems should still be classed as modems, since they use complex waveforms to carry digital data. They are more advanced devices than traditional dial-up modems as they are capable of modulating/demodulating hundreds of channels simultaneously."
Hopefully this dumbing down of language doesn't creep into areas where specific words are used to convey precise meanings, like medicine or engineering.
You have a strange notion of "every change" and "every file".
I've been using version control for all sorts of stuff for many years now, starting with Subversion when it was a couple years old (I'd guess 2004ish, when I was in mid-undergrad) and more recently Git. I've got lots of stuff in version control: basically every program I've worked on for more than about an hour, many text documents, basically all of my config files on my Linux work box, etc. I can get at least as worked up about what version control software to use in a project as I do about, say, what programming language to use. (E.g. I hate CVS with the fire of a thousand suns.) I have, on many occasions, written longer commit logs than the diff of what I'm committing.
And I'd still like to try an actual, legitimate versioning file system. Why? Because I'm not perfect. I occasionally forget to commit something, or be mistaken about whether I've done it. Or I'll misjudge how fine I should make my commits, and make too many changes at once. Or sometimes I'll even be working on a file outside of version control. (I bet you have some of those too!)
Now, version control is awesome, and you get a number of things that you wouldn't from a versioning file system. In particular, you get (hopefully) information about what constitutes a single semantic change. You know that these three edits to A.txt and these two edits to B.txt constitute one change, and, say, making those three edits to A.txt doesn't make sense if you don't make B.txt's edits as well. (Maybe one is a header file and the other a source file.) With a versioning file system, that one semantic change looks like five independent edits, so there's not much you can do to correlate even all three edits to A.txt, let alone across files. (And this doesn't even get into some of the fancier things you can do especially with the recent DVCSs like rewriting history to make clean patch sets.)
However, using version control does have a quite bit of overhead in figuring out where you want to store the repository, how much you want to commit, what granularity you want the repository to cover (this is especially important with Git over, say, Subversion and getting it wrong can cause you to have to go through quite a bit of work later), etc. Then you actually have to go and commit all of the files each time you want to.
In other words, while the two cover similar needs, they really don't fully overlap, and I think there would be room for both. This would especially be true if your file system and VCS communicated, or were even part of the same system.
(Then again, I also sometimes wish I had the entire edit history of some of the stuff that I do, down to "I selected this sentence, deleted it, and wrote this other thing instead" that happened between saves. What I'd love to see is to have a slider or something that would let you travel through time and see old versions of the files; at the coarsest granularity would be, say, commits to version control, then at the next level would be file saves, then at the finest level would be the actual edits. Making such a system usable though is probably pretty close to AI-hard...)
I've always wished they'd add a new level to PV in that when file is deleted a snapshot is taken then as well rather than just at the set times.
The technical reasons they can't really do that without a fair bit of work is that PV is built on the Volume Shadow Copy feature. And as that name indicates (a bit obliquely), it operates on an entire volume, not on the level of a single file. So that would leave MS a choice: take a VSS snapshot of the entire drive containing the file you're deleting, or implement an extension to PV in an entirely different way.
(That being said, it would certainly be far from impossible. I wouldn't be surprised if someone could code up some preliminary support in a day. But then it has to go through QA and user research and who-knows-what-else jazz.)
Finally, it is stored on the same bloody partition let alone same physical drive making it useless for disaster recovery. It is not a replacement for time machine because backups belong on a separate drive which is preferably external to the computer.
I think you've missed a lot of the point of the Previous Versions feature. It isn't designed to give you "my power supply entered a murder-suicide pact with my hard drive" recovery, it's designed to give you "oh crap did I delete that?" recovery.
A while ago I was looking into what snapshot support various file systems have, and I was actually disappointed by the fact that Time Machine apparently requires an external drive, which was not at all what I wanted. Windows's VSS support was actually much closer. So to each his own. (Not that Time Machine would have been an option anyway. Apple won't sell me a copy of OS X that I can legally use and they don't sell a midrange desktop, so OS X is out of the question for me on the desktop anyway.)
As someone who has spent more time than I'd care to admit fantasizing about what I'd want in a file system, what your parent describes is not really like Windows's VSS. (Well, it is sort of like it, but there are still important differences.)
Most notably, VSS only takes snapshots at particular intervals, so if there are multiple changes between those intervals (almost always set very far apart); something like the file system that at least I wants, and what the parent describes, would store every copy.
That being said, a log-structured file system doesn't solve the fragmentation problem unless you like buying hard drives drives because you never reclaim space. (There are things you can do to make it harder to wind up fragmented, but there's no way to avoid it entirely short of moving existing files around when adding new ones, which is essentially implementing an incremental defragmenter.)
Slashdot Mirror
So for the Valve titles, even if you get the physical media, you still have to play through Steam. Essentially the only difference between buying the electronic copy and the retail version is the discs eliminate most of the download step. (E.g. if Steams servers went away, you wouldn't be able to play the game from the retail discs.)
Yeah, but that sort of thing can happen now. The new law wouldn't change that fact.
As reply-all is something that should only rarely be used...
"I don't use it" doesn't mean "other people don't use it". I'd actually say that half the emails I send are reply all.
Because in this context "free" sometimes means "freely available to use", sometimes it means "sorta freely available to use, but you need to mention us in your docs" and sometimes it means "impossible to use, due to proprietary license that may (or may not) allow you to link to this code at all".
And to be fair, sometimes it means "impossible to use, due to a copyleft license that disagrees with this other copyleft license." Hell, you can't even use GPL v2-only and GPL v3 code together, let alone something like GPL and the CPL.
You say "either what you're doing is a derivative work or not" as if that's an easy thing to determine. It isn't necessarily.
Their estimated temperature was one of the things that made it look "Earth-like", and it's one of the measurements they are needing to revise that make it no-longer look Earth-like.
Not saying that everything going on today is an improvement but... you have a much-overromanticized version of history.
IMHO it's more logical to avoid such large numbers by using decimal points. Release 4.1, 4.2, 4.3 this year, not 5, 6, 7.
That's only a clear win if there's some notion of compatibility (either programmatic or user experience) that you're maintaining among the 4.x releases, and even then it may not be. E.g. I find the progression of Linux kernel versions to be increasingly ridiculous; I'd rather see "the current stable release is 37.2 and the current unstable release is 38-rc7" than "the current stable release is 2.6.37.2 and the current unstable is 2.6.38-rc7".
If you stick to the point releases when there's no discernible big jump in features or whatever in a new release, as is what Linux is doing and what Mozilla wants to do, you've just turned "Chrome and Firefox will be up to version 40-something" to "Chrome and Firefox will be up to version 4.40-something", because if there are no stand-out updates, when do you bump the major revision number?
Everything I have read states 25 years TOPS
Depends on what you mean by "lasts"; they degrade gracefully, not fail suddenly. Wikipedia and other sources say that several manufacturers warranty their panels at 80% output at 25 years. I'd consider that lasting well past 25 years.
Not according to unix.org. What you are talking about is the C99 standard which isn't about data models but a specific programming language specification.
'long long' was a common compiler extension well before C99. It was available by at least GCC 2.7.2.3, which was released Aug 1997. That's the earliest version I have access to without compiling stuff.
And to some extent you're right about the disconnect about the data model and C language -- but at the same extent, IMO they're so tightly coupled in Unix that I also think it's reasonable to talk about what was going on in the world of C.
However you would have to maintain those data structures forever instead of relying on MS data types. Or you could the very messy task of putting in #IFDEF everywhere to separate your 64-bit/32-bit parts if you wanted to use the MS data types but keep one version of source code. You could do all of that. Or you could maintain two versions. I would think it's far easier to maintain two versions.
While I'll admit that I don't have a ton of experience with coding in "the Windows way" using all their DWORD and LPVOID jazz, and I don't know exactly what effect the 64-bit switch has on them, I'm still not really seeing the problem. C provides 'intptr_t' for an address-sized integer, and Windows provides ULONG_PTR and DWORD_PTR. All of these types behave like 'long' does under Linux: it's 32-bit when compiling for a 32-bit target and 64-bit when compiling for a 64-bit target.
See my reply to myself that I wrote almost immediately.
I was off in some fantasy world where code was actually generally well-written and didn't make architecture-specific assumptions about the size of integers.
That said, you still have a couple things wrong. First, LLP doesn't really "introduce" long long; that's been usable even in 32-bit software for ages. Second, while you do have to do some rewriting to get your code 64-bit clean if you aren't in my magical fantasy world, it's absolutely wrong to say you then need to maintain two source trees.
You make a lot of assumptions here, and I don't think that they necessarily pan out in practice.
The whole point of using Windows is backwards compatibility.
That's part of it, but it's not the whole story. For instance, I use Windows on my home box partially because I'm one of those strange people who actually like it. (Actually that's not quite true; in reality, I tend to like Linux and Windows about the same, and I dislike both. But the important thing is that Linux and Windows annoy me in different ways, and I use Linux at work, so by running Windows at home I get some variety in my frustration instead of it always being focused on one thing.)
Now I do have some Windows-only software that I use (a couple games and Adobe Lightroom), but 90% of the time I've just got stuff that has easy cross-platform replacements.
Which brings me to my next point:
Microsoft would have to use dynamic translation techniques ... and any power consumption advantage that ARM may have would be more than eliminated.
But what if they only have to use those dynamic translation techniques 5% or 10% of the time? There are a lot of people whose use probably falls under that: most of the time they're using software they could get ARM versions of easily enough, or change to a slightly different program if they couldn't, and then once every few days they'd use a program that would need binary translation.
Now, does that apply to everyone? No. But I think it would apply to most people. (Look at how many people have switched to doing a lot of stuff on their iPhones and iPads.) The bigger question is how savvy you'd need to be to pick up the fact that you should and could get a new version of the software. (And here again I think it'd be reasonably easy to do that.)
Finally, who says that ARM needs to be confined to systems where battery life is important? I'm waiting with somewhat baited breath for more information about nVidia's Project Devner. Those are chips meant for desktops and servers. Will they be good enough to pick over whatever Intel and AMD have out at the time? I dunno... quite possibly not. But they may well be. And that would be very exciting.
Uh what? I'm curious what characteristics of the Windows model meant that the similar "recompile" model wouldn't work on Windows. Because I don't know of any.
Actually that's not quite true; I can think of at least one difference: if you use native C types and use a long to store a pointer value. With the typical Windows model, that would result in a truncation; with the typical Linux model, that would continue to work.
That said, that code is latently broken anyway; in some sense it doesn't deserve to work in the first place. But that doesn't mean that the Windows crew has to maintain two source trees; that's ridiculous. What it means instead is that if you have an 'int' variant that you want to hold an address, you should use 'intptr_t' instead. Which is what the Linux software should be doing anyway.
Software companies that wanted to take advantage of 64-bit for Windows had to maintain separate 32-bit and 64-bit binary and source code versions during the migration. ... A 32-bit program could be made into a 64-bit program with a recompile and testing to ensure there were no special scenarios that required 32-bit addresses, etc. Software companies would have to maintain two binary versions but for the most part could maintain one version of source code.
Uh what? I'm curious what characteristics of the Windows model meant that the similar "recompile" model wouldn't work on Windows. Because I don't know of any.
I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?
XP 64 got off to a bit of a bad start, but I havn't run anything but 64-bit Windows on my home system for years; that goes back to the pre-Win 7 era (I was running 64-bit Server 2008 for a year or so).
And even the XP case is overstated, at least nowadays. Until fairly recently I was running 64-bit XP at work (I've switched to Linux); several other people in my group still are. It works fine.
I haven't, for either. That being said, I'd be extraordinarily surprised if it worked in the case of the Oregon Trail, as my understanding is that Win 7 doesn't have 16-bit support period. I'm not sure what I'd set it to for Guitar Hero; there isn't a separate "32-bit XP" option or anything, and it doesn't claim to support previous versions. You never know, it could work... but I doubt it. (I also did some searches for workarounds, which is how I found out about Orca, and didn't see anything about it.)
(Also note that I'm not the OP you were replying to, just in case that wasn't clear from my last post.)
"Those who don't understand UNIX are condemned to reinvent it, poorly."
I have my own corollary: "Those who understand Unix are condemned to invent it, well." (Read that in a somewhat insulting way and you get the idea.)
As someone who uses both Windows and Linux a lot, there's a lot to like and a lot to hate about both systems. I think Windows, especially recent versions, gets a bad rap amongst CS folks. And I think that there are a lot of things about Unix that I describe as persisting because the people who work on it refuse to acknowledge it's no longer 1975. (This is being deliberately antagonistic, and it overstates my feeling, but it does get the essence.)
For example, I've been involved in a few discussions over the years here about what a file system should look like for instance, and saying things like that I think Transactional NTFS is awesome and I wish *nixs would support it -- and I've gotten almost nearly unanimous dissent amongst Unix oldbeards. That's something MS has done right, and it's a huge pity that you can't write cross-platform software that uses a transactional file system.
This isn't to say Windows is perfect: it isn't, not by any stretch of the imagination. It's got implementation issues (buffer overflows), configuration issues (largely borne out of a desire for backwards compatibility), and what I feel it's biggest problem going forward is, which is an API that... is not very clean in many respects. (E.g. Unix's fork/exec method of process "creation" is way cleaner than CreateProcess because the latter has to take into account lots of stuff (changing the environment, remapping file descriptors, etc.) that you would do between fork and exec on Unix.)
I can sort of give you two examples, though that fail because of the 64-bitness of my Win 7 installation rather than the Windows version specifically. First is The Oregon Trail II; this is a 32-bit program but has a 16-bit installer. So the installer won't run. (You can install to, say, a VM then copy stuff over.) Second example is Guitar Hero 3. That checks for 32-bitness and (because I'm pretty sure that Aspyr produced that Windows port by taking the console code and taking a shit on it) fails if it's 64-bit. (You can edit the MSI with a program called Orca to remove that check, and then things install.)
It's not quite irrelevant to everyone because there are a lot of crappy scripts (especially written by people who run *nix) that assume that your paths don't have spaces in them.
But it is almost entirely irrelevant.
I know that it is not a an analogue for time machine but a lot of Apple detractors try to paint Shadow copy as the same thing as time machine which it obviously isn't.
I'll back off a little bit. That being said, while the original poster mentioned Time Machine, he also talked about perhaps implementing it with something like LogFS. (For those unfamiliar with that, think of it as a COW system. Keep around the old metadata and you have access to the old versions of files.) Along with the motivation of why he wants it (a "replacement" for the trash/recycle bin), that indicates to me that what he wants is an in-filesystem solution. VSS is thus closer to being that than Time Machine is, especially from a technical point of view. Because of this, it was appropriate for your parent to bring it up VSS as being similar, and pretty irrelevant for to go complaining about it not providing disaster recovery.
AT&T supplied me with a small piece of hardware for my adsl connection. AT&T refers to it as a modem even though it doesn't modulate or demodulate anything.
Wikipedia disagrees: "Broadband modems should still be classed as modems, since they use complex waveforms to carry digital data. They are more advanced devices than traditional dial-up modems as they are capable of modulating/demodulating hundreds of channels simultaneously."
Hopefully this dumbing down of language doesn't creep into areas where specific words are used to convey precise meanings, like medicine or engineering.
I hope it doesn't cause any heart attacks.
You have a strange notion of "every change" and "every file".
I've been using version control for all sorts of stuff for many years now, starting with Subversion when it was a couple years old (I'd guess 2004ish, when I was in mid-undergrad) and more recently Git. I've got lots of stuff in version control: basically every program I've worked on for more than about an hour, many text documents, basically all of my config files on my Linux work box, etc. I can get at least as worked up about what version control software to use in a project as I do about, say, what programming language to use. (E.g. I hate CVS with the fire of a thousand suns.) I have, on many occasions, written longer commit logs than the diff of what I'm committing.
And I'd still like to try an actual, legitimate versioning file system. Why? Because I'm not perfect. I occasionally forget to commit something, or be mistaken about whether I've done it. Or I'll misjudge how fine I should make my commits, and make too many changes at once. Or sometimes I'll even be working on a file outside of version control. (I bet you have some of those too!)
Now, version control is awesome, and you get a number of things that you wouldn't from a versioning file system. In particular, you get (hopefully) information about what constitutes a single semantic change. You know that these three edits to A.txt and these two edits to B.txt constitute one change, and, say, making those three edits to A.txt doesn't make sense if you don't make B.txt's edits as well. (Maybe one is a header file and the other a source file.) With a versioning file system, that one semantic change looks like five independent edits, so there's not much you can do to correlate even all three edits to A.txt, let alone across files. (And this doesn't even get into some of the fancier things you can do especially with the recent DVCSs like rewriting history to make clean patch sets.)
However, using version control does have a quite bit of overhead in figuring out where you want to store the repository, how much you want to commit, what granularity you want the repository to cover (this is especially important with Git over, say, Subversion and getting it wrong can cause you to have to go through quite a bit of work later), etc. Then you actually have to go and commit all of the files each time you want to.
In other words, while the two cover similar needs, they really don't fully overlap, and I think there would be room for both. This would especially be true if your file system and VCS communicated, or were even part of the same system.
(Then again, I also sometimes wish I had the entire edit history of some of the stuff that I do, down to "I selected this sentence, deleted it, and wrote this other thing instead" that happened between saves. What I'd love to see is to have a slider or something that would let you travel through time and see old versions of the files; at the coarsest granularity would be, say, commits to version control, then at the next level would be file saves, then at the finest level would be the actual edits. Making such a system usable though is probably pretty close to AI-hard...)
I've always wished they'd add a new level to PV in that when file is deleted a snapshot is taken then as well rather than just at the set times.
The technical reasons they can't really do that without a fair bit of work is that PV is built on the Volume Shadow Copy feature. And as that name indicates (a bit obliquely), it operates on an entire volume, not on the level of a single file. So that would leave MS a choice: take a VSS snapshot of the entire drive containing the file you're deleting, or implement an extension to PV in an entirely different way.
(That being said, it would certainly be far from impossible. I wouldn't be surprised if someone could code up some preliminary support in a day. But then it has to go through QA and user research and who-knows-what-else jazz.)
Finally, it is stored on the same bloody partition let alone same physical drive making it useless for disaster recovery. It is not a replacement for time machine because backups belong on a separate drive which is preferably external to the computer.
I think you've missed a lot of the point of the Previous Versions feature. It isn't designed to give you "my power supply entered a murder-suicide pact with my hard drive" recovery, it's designed to give you "oh crap did I delete that?" recovery.
A while ago I was looking into what snapshot support various file systems have, and I was actually disappointed by the fact that Time Machine apparently requires an external drive, which was not at all what I wanted. Windows's VSS support was actually much closer. So to each his own. (Not that Time Machine would have been an option anyway. Apple won't sell me a copy of OS X that I can legally use and they don't sell a midrange desktop, so OS X is out of the question for me on the desktop anyway.)
As someone who has spent more time than I'd care to admit fantasizing about what I'd want in a file system, what your parent describes is not really like Windows's VSS. (Well, it is sort of like it, but there are still important differences.)
Most notably, VSS only takes snapshots at particular intervals, so if there are multiple changes between those intervals (almost always set very far apart); something like the file system that at least I wants, and what the parent describes, would store every copy.
That being said, a log-structured file system doesn't solve the fragmentation problem unless you like buying hard drives drives because you never reclaim space. (There are things you can do to make it harder to wind up fragmented, but there's no way to avoid it entirely short of moving existing files around when adding new ones, which is essentially implementing an incremental defragmenter.)