Oh, thats silly. Its great, it means website video content can be transcoded in 2 formats and have a fallback flash or silverlight implementation.
As opposed to just a Flash implementation that works decently well almost everywhere?
Unless you were being facetious, how is having three ways to do the same thing for not a whole lot of benefit a great thing? (I mean, I *am* looking forward to being able to dump Flash, but at the same time I don't see it as a big improvement to stick that in the browser itself.)
If it's wrong, explain why it's wrong. Modding it down leaves us no idea whether the anonymous silent modder is the one in the right, or not.
The problem is that there are often posts already that explain why it's wrong (just like there were two posts before mine in reply to the one that's wrong here)... at that point adding another post doesn't really contribute anything.
While it's not really a problem here, it's not terribly infrequently that I see a just plain-old, blatently-wrong post that is moderated up to (+4, Insightful) or (+5, Informative), or something like that. And there's not really anything terribly fitting moderators can do... it clearly doesn't deserve to stay moderated up, but none of the negative mods really fit. (-1, overrated) is the best, but (1) IIRC it can't be metamoderated, and (2) doesn't do anything about the insightful/informative/interesting tag, so when another moderator comes along who's not paying attention to the story or to the replies, they'll often just go "oh, it has only had enough + mods to get to +4; I'll bump it up to +5."
Maybe the best solution is to either add a (0, wrong) mod that adds a descriptive tag without changing the score, or add a (-1, wrong) mod that can't help lower a post past +1 or 0 or something like that.
Note that this is the EXACT same situation as the iPhone. You have been able to shoot video on the iPhone once jailbroken.
It's exactly the same, except that there's a fair chance that one of the two is (however unreasonably) illegal and in a community that is somewhat underground, while the other has freedom as at least somewhat of a distinguishing characteristic of the platform.
I'm in the process of applying for a software patent myself (I know, summon the chorus of boos; but having it could be the difference between being able to raise VC and not being able to raise VC for my starting business; loans, too, are often secured against your IP). These things don't come cheap -- mostly in terms of legal costs. As in a $5k retainer, $5-10k total for a single patent, more if it takes multiple patents to ensure sufficient protection, and if you want international protection, it can go up to $100k or so.
IBM has staff lawyers; they aren't paying standard retainer fees like you are.
Server-side? Oh, please, do you really trust old rusty UA sniffing? Do you trust the headers? Are the headers your server receives really sent by the UA or are they sent by some proxy? Oh, please, don't. Client-side, the media attribute or @import rulez!
I'm not a web programmer, so I don't know all the different ways to do this sort of thing. It certainly seems conceivable that there would be a way to detect it server-side, though I do know enough to not look at the UA. I also know that you can have alternate CSS media settings like display and printing, but I don't know if there's a standard "mobile" option there or something like that. If so, that'd be client side, but have the same ultimate effect.
But at the very least, you could have a "click here for the mobile version" link that would tell the server to give the mobile verison.
If the server modifies the source to deliver alternate CSS, the content is not the same.
I was more thinking about delivering the same content but different CSS at the same URL, but either way works.
If this seems somewhat pedantic: Save a server-modified page with your mobile appliance, then view it on your wide-screen-something-killer-PC. Or vice versa.
I would say it's still somewhat pedantic, at least for now.;-) (Though I do agree if there's a way to do it without that, like media switching, that'd be better.)
remember when Javascript would "disable right-click", but download to your temp folder?
Yes, it would have a similar effect. (That said, browsers now often prevent, or have the option to prevent, rightclick javascript hijacking, and even when they didn't it was often possible to break anti-right-click scripts with things like left button down, right button down, left up, right up, or other similar sequences.
Right click - copy ".swf" file
Even if this works, that's a pretty crappy format to have the picture in, so you have to go through the screenshot-copy-paste-crop dance later. Might as well do it in the first place. (Hell, that'll often be easier than going to the cache even for image files.)
You are right: it is "more involved" for the average Joe...
It's "more involved" -- quite a bit more involved -- for everyone.
You are right: it is "more involved" for the average Joe, but who cares if he takes it? He probably won't have the know how to be making money by stealing your images anyways. This is the digital age, and preventing images from being copied is the same problem that the RIAA/MPAA currently face. Anything can be replicated/saved if it comes from the computer.
I definitely agree with all of this. I was never quite sure what exactly the goal was of these websites. If it is to discourage casual copying from visitors to their site, then I would argue embedding photos in flash is pretty darn effective at it. If it is to prevent the spread of their images to other sites by people who have a real interest in getting access to them... no, there's no way to do that.
Not just that, but it may not even be necessary for the device to do anything terribly smart. If you can detect that it's a mobile device on the server-side, you can feed it a different style sheet that will change how it displays so it's more mobile-friendly. Same content, different CSS.
Sure, you can save it. That doesn't mean that using the flash trick doesn't (1) make it harder, (2) make it more annoying, or (3) even make it so some people don't have to do it.
Compare the two steps:
Without Flash: 1. Right click 2. Click save as 3. Navigate to the folder (which you very well may already be in as browsers save that even between sessions) 4. hit save
With Flash (on Windows and without other software few people have installed): 1. Press printscreen 2. Open an image editor (a whole other program!), say paint 3. Crop the image to the part you want to save 4. Click file, save as (or ctrl-s) 5. Navigate to the folder (which you are less likely to be in, and if you're using Paint will almost certainly NOT be in) 6. hit save
Even if you leave the image program open, thus eliminating step 2 and the problem of remembering folders, you still have more steps including an annoying one of cropping.
I have definitely not saved images because sites have done this flash thing, and I have no doubt I'm not alone in that.
Shims allow Microsoft to fix bugs in Windows without affecting applications.
The other (and probably bigger) thing they allow MS to do is fix bugs in other applications they don't have source code to without affecting Windows.
Tons of programs out there make unwarranted assumptions about how functions will behave -- that handles are actually pointers, that a function treats an unused out parameter in a specific way, even that programs or dialogs have controls laid out in a specific way. Shims allow MS to change the implementation of the functions without changing the contract.
(This is distinguished from your example because, in your example, the CreateFileEx contract is actually changing, and the old API spec and/or Windows is buggy. In my example, the contract remains the same, and the program is buggy.)
There is a Linux distribution called GoboLinux that makes this the norm. Installing a program puts it into its own directory but also sets up some symlinks and such in/bin so that you can still call it.
It's actually quite a spiffy idea, though I haven't actually tried it. (A friend did try the package manager on another system since we wanted a package manager that doesn't require root (*remarkably* hard to find actually -- all of the major ones seem to require it; being able to install programs as non-root is one place where Windows actually wins quit a bit at, since it's usually possible, while on Linux you're thrown back into the days before package managers when you had to go through the bitch of resolving dependencies manually) without much luck, but that might have just been the weird quirks of what we were trying to do instead of anything in GoboLinux itself.)
Are you sure it was the application writer's bad practices that forced many apps to require admin privileges? Because the phenomenon of having to run most day to day apps as an admin seems to be limited to Windows.
It's a mix of blame. On one hand, there are (and have been) plenty of programs out there that don't require admin rights, and there have been for a long time. We used several on NT 4 boxes back when I was in school. So it's not like MS has made it impossible to develop them, or even much harder than it would be to develop a non-root program on Unix.
The part that MS does have some blame for is the long history of not even trying to encourage the practice. 95 didn't really have any security to speak of, and a lot of programs just targeted that platform. (Games come to mind here.) Even on NT, by default I think users had admin rights. Because almost everyone ran as admin anyway, there was little need to write your program to support limited users, which meant that app developers didn't do it.
(Damn it, this firefox extension I have will occasionally cause focus to jump around, and it just happened to jump to the submit button before I was done. Advice: if you use Hit-A-Hint or its successor, LOL -- otherwise awesome BTW -- don't set 'space' to be one of the magic keys.)
Anyway:
How 'bout pre OS X? I mean, OS X is only, what, 10 years old? That's less than half the age of many programs that will still run.
Finally, I have all kinds of DOS or windows 3.11 apps that don't run well or at all on windows any more, even in emulation mode.
There are plenty of ones that don't run, but there are plenty that do, and "runs some" is better than almost any other platform's binary compatibility if you look at the time frame of the early 90s.
(Though if you want to see serious backwards compatibility, IBM's highest-end mainframes, the zSeries, still run System/370 binaries from the early 70s.)
Just to play devil's advocate, linux runs any X11 app and that goes back decades and decades (e.g., nethack is from 1985).
If you recompile it. I would be astounded if you could take a nethack binary from before Linux was invented and run it on Linux.
By contrast, there are DOS programs older than Nethack that still run under 32-bit Vista. Binaries.
Also, often apps that runs on OS X can run on any version of OS X but there were some changes between point releases but I don't know of an app that fails to run on new versions.
How 'bout pre OS X? I mean, OS X is only, what, 10 years old? That's less
The whole reason shims exist is because the APIs change over time, so what was correct usage in Win2000 or WinXP might not be correct in Vista or 7.
Well, depending on how you interpret that statement, that's only part of the reason, because MS rarely breaks an API in a backwards-incompatible way.
There are basically two reasons why software stops working on windows:
1.) It makes assumptions that are at a higher level than what the API does. For instance, that the user is running as administrator. At least on the NT line, it has never been the case that the API has "allowed" a program to assume that a requested access to HKEY_LOCAL_MACHINE will succeed, or that it can write to Program Files. (Starcraft crashes at the end of a game when run as a limited user under XP -- presumably because it tries to write LastReplay to Program Files.) Even if the API can theoretically return an 'access denied' error, the programmer assumes that it won't actually arise in practice.
Another example of this is DOS programs that assume they can access the hardware directly and stuff like that, which "of course" doesn't work under NT.
2.) It makes assumptions that are not part of the API proper, but just artifacts of the implementation. For instance, assuming HANDLEs (which the API says should be opaque) are pointers which can be directly accessed (which is true in version A but not true in version B). One good example of how subtle this can be is a shell namespace extension that implemented a function signature wrong by giving the wrong number of arguments. This creates the strong potential for stack corruption. On Windows 95 and NT 4, it worked because Windows was compiled with frame pointers, which left it robust to that error. With Windows 2000, Windows was compiled with the frame pointer optimization, which meant that program crashed Explorer. At no point was "Windows will be compiled with frame pointers" part of the API.
(Then there are higher level problems of a similar nature. There are programs that will open up the display properties dialog then send tab messages or otherwise enumerate the controls present, then change, say, the fifth control so it has the setting they want. What if MS changes the tab order or adds a new control? Boom.)
So if you say that "the APIs change over time" means that their defined behavior changes, this is the decidedly minor aspect of compatibility problems. It's only if you allow implementation-specific details to creep in (which I don't consider part of the API) that your statement is true.
The line between humor and seriousness can be very thin at times.
One of my favorite quotes about gay marriage was said by Jon Stewart during an interview of him, which was something like "At first I was really against it. Because I love my wife. And then I realized that it wouldn't be mandatory."
Cut the power, seriously? Cuz there's nothing safer than suddenly losing engine power at 150 kph. Power steering, breaks, manouverability- all go out the window.
Yeah, good thing that doesn't happen.
(I know, the summary didn't convey that very well.)
Also, why use GPS for this? That's a surefire way to introduce errors into the system. Why not just hook into the cars existing speedometer?
That's a good idea. But the speedometer would need to know what the current speed limit is so it knows what to limit to. I know, maybe we could put a network of satellites in orbit from which we could derive our position, figure out what road is at that position, then look up the limit in some database.
FTFA, looks like what it allows is arbitrary execution of Java code. So it wouldn't be architecture-specific at all, unless you started using architecture-specific stuff in said code. If you've got the JVM to exploit, then you've got the JVM to run stuff on.
That would probably completely invalidate the results though, for two reasons. First, the sorts of people who would opt into that wouldn't at all be representative. (It would take an unusual person to even find the opt-in, let alone volunteer for a degraded experience knowingly.) Second, knowing about it would be way too likely to affect how the people behaved.
You could get halfway by saying "would you like to help us do research" or something like that, without saying in what way, which would reduce these problems, but not completely.
I can definitely buy that something like that helps with the individual commits thing (I didn't see it *explicitly* listed as a feature, but it wouldn't be all that hard to add once you have repository browsing support (which is listed as a feature of Meld), but I fail to see at all how that helps with the first problem, since you're still looking at the Tex source.
I'm going to start off by saying that good interaction with version control is, I think, the single biggest benefit Latex offers over Word for the sorts of things that I do, at least pre-submission time. (This is probably partly borne out of a overly enthusiastic perspective on version control, but it's definitely up there.)
That said: track changes does have a few benefits over SCM use. First, it's much more user friendly if you are reading to see what's changed. (Ironically, this is most important when you have collaborators, which is when VCSs shine brightest.) SCMs will give you diffs, but it's diffs of the Tex source code. I don't know about you, but I really don't like trying to read that, especially if some misguided soul hit meta-q and changed the line breaks. An alternative is to use something like latexdiff, which overall is pretty awesome, but can be kind of clunky to use and, in my experience, has often needed a few manual changes to the output before the result compiles.
Second, track changes doesn't just show you what changed or give you a way to accept or reject a full revision, which VCSs make easy, but gives you much finer-grained control on what specific changes to accept or reject. You can cherry-pick changes; this sentence's changes are good, this sentence's changes are bad. To get the same effect with a version control solution you would need to save and commit after every individual changes to the document. I make pretty fine-grained commits, and even I am a long way away from that level.
And, more importantly, does it nicely support semantic markup and allow the user to extend the semantic definitions?
Word has long (that is, decades long) supported what I would call semantic markup, even if it's more hidden than the bold/italic/underline/font size buttons on the toolbar. You can make your own styles that inherit from existing styles, and stuff like that.
You can't do programming in the same sense as Tex (at least not without macros, and I don't know if they do anything like what you'd want) so it is more restrictive, but Word is much closer to the content/presentation separation model than many Tex-heads give it credit for, at least if you use it that way.
Word's biggest shortfalling in this sense is that it's easier to do it the wrong way than it is to do it the right way, where it's usually the other way around in Tex.
Does it nicely typeset source code and algorithm descriptions?
You could, though the problem here is that it's much more tedious to do any sort of syntax highlighting. In Latex, at least depending on the package you're using, you can just toss a \ before any keywords or whatever in your code, while I don't know of any good way of doing the same in Word.
Slashdot Mirror
Oh, thats silly. Its great, it means website video content can be transcoded in 2 formats and have a fallback flash or silverlight implementation.
As opposed to just a Flash implementation that works decently well almost everywhere?
Unless you were being facetious, how is having three ways to do the same thing for not a whole lot of benefit a great thing? (I mean, I *am* looking forward to being able to dump Flash, but at the same time I don't see it as a big improvement to stick that in the browser itself.)
If it's wrong, explain why it's wrong. Modding it down leaves us no idea whether the anonymous silent modder is the one in the right, or not.
The problem is that there are often posts already that explain why it's wrong (just like there were two posts before mine in reply to the one that's wrong here)... at that point adding another post doesn't really contribute anything.
While it's not really a problem here, it's not terribly infrequently that I see a just plain-old, blatently-wrong post that is moderated up to (+4, Insightful) or (+5, Informative), or something like that. And there's not really anything terribly fitting moderators can do... it clearly doesn't deserve to stay moderated up, but none of the negative mods really fit. (-1, overrated) is the best, but (1) IIRC it can't be metamoderated, and (2) doesn't do anything about the insightful/informative/interesting tag, so when another moderator comes along who's not paying attention to the story or to the replies, they'll often just go "oh, it has only had enough + mods to get to +4; I'll bump it up to +5."
Maybe the best solution is to either add a (0, wrong) mod that adds a descriptive tag without changing the score, or add a (-1, wrong) mod that can't help lower a post past +1 or 0 or something like that.
More proof /. needs a (-1, wrong) mod.
Note that this is the EXACT same situation as the iPhone. You have been able to shoot video on the iPhone once jailbroken.
It's exactly the same, except that there's a fair chance that one of the two is (however unreasonably) illegal and in a community that is somewhat underground, while the other has freedom as at least somewhat of a distinguishing characteristic of the platform.
I'm in the process of applying for a software patent myself (I know, summon the chorus of boos; but having it could be the difference between being able to raise VC and not being able to raise VC for my starting business; loans, too, are often secured against your IP). These things don't come cheap -- mostly in terms of legal costs. As in a $5k retainer, $5-10k total for a single patent, more if it takes multiple patents to ensure sufficient protection, and if you want international protection, it can go up to $100k or so.
IBM has staff lawyers; they aren't paying standard retainer fees like you are.
Server-side? Oh, please, do you really trust old rusty UA sniffing? Do you trust the headers? Are the headers your server receives really sent by the UA or are they sent by some proxy? Oh, please, don't. Client-side, the media attribute or @import rulez!
I'm not a web programmer, so I don't know all the different ways to do this sort of thing. It certainly seems conceivable that there would be a way to detect it server-side, though I do know enough to not look at the UA. I also know that you can have alternate CSS media settings like display and printing, but I don't know if there's a standard "mobile" option there or something like that. If so, that'd be client side, but have the same ultimate effect.
But at the very least, you could have a "click here for the mobile version" link that would tell the server to give the mobile verison.
If the server modifies the source to deliver alternate CSS, the content is not the same.
I was more thinking about delivering the same content but different CSS at the same URL, but either way works.
If this seems somewhat pedantic: Save a server-modified page with your mobile appliance, then view it on your wide-screen-something-killer-PC. Or vice versa.
I would say it's still somewhat pedantic, at least for now. ;-) (Though I do agree if there's a way to do it without that, like media switching, that'd be better.)
remember when Javascript would "disable right-click", but download to your temp folder?
Yes, it would have a similar effect. (That said, browsers now often prevent, or have the option to prevent, rightclick javascript hijacking, and even when they didn't it was often possible to break anti-right-click scripts with things like left button down, right button down, left up, right up, or other similar sequences.
Right click - copy ".swf" file
Even if this works, that's a pretty crappy format to have the picture in, so you have to go through the screenshot-copy-paste-crop dance later. Might as well do it in the first place. (Hell, that'll often be easier than going to the cache even for image files.)
You are right: it is "more involved" for the average Joe...
It's "more involved" -- quite a bit more involved -- for everyone.
You are right: it is "more involved" for the average Joe, but who cares if he takes it? He probably won't have the know how to be making money by stealing your images anyways. This is the digital age, and preventing images from being copied is the same problem that the RIAA/MPAA currently face. Anything can be replicated/saved if it comes from the computer.
I definitely agree with all of this. I was never quite sure what exactly the goal was of these websites. If it is to discourage casual copying from visitors to their site, then I would argue embedding photos in flash is pretty darn effective at it. If it is to prevent the spread of their images to other sites by people who have a real interest in getting access to them... no, there's no way to do that.
Not just that, but it may not even be necessary for the device to do anything terribly smart. If you can detect that it's a mobile device on the server-side, you can feed it a different style sheet that will change how it displays so it's more mobile-friendly. Same content, different CSS.
Try that with your nested tables.
Sure, you can save it. That doesn't mean that using the flash trick doesn't (1) make it harder, (2) make it more annoying, or (3) even make it so some people don't have to do it.
Compare the two steps:
Without Flash:
1. Right click
2. Click save as
3. Navigate to the folder (which you very well may already be in as browsers save that even between sessions)
4. hit save
With Flash (on Windows and without other software few people have installed):
1. Press printscreen
2. Open an image editor (a whole other program!), say paint
3. Crop the image to the part you want to save
4. Click file, save as (or ctrl-s)
5. Navigate to the folder (which you are less likely to be in, and if you're using Paint will almost certainly NOT be in)
6. hit save
Even if you leave the image program open, thus eliminating step 2 and the problem of remembering folders, you still have more steps including an annoying one of cropping.
I have definitely not saved images because sites have done this flash thing, and I have no doubt I'm not alone in that.
Shims allow Microsoft to fix bugs in Windows without affecting applications.
The other (and probably bigger) thing they allow MS to do is fix bugs in other applications they don't have source code to without affecting Windows.
Tons of programs out there make unwarranted assumptions about how functions will behave -- that handles are actually pointers, that a function treats an unused out parameter in a specific way, even that programs or dialogs have controls laid out in a specific way. Shims allow MS to change the implementation of the functions without changing the contract.
(This is distinguished from your example because, in your example, the CreateFileEx contract is actually changing, and the old API spec and/or Windows is buggy. In my example, the contract remains the same, and the program is buggy.)
There is a Linux distribution called GoboLinux that makes this the norm. Installing a program puts it into its own directory but also sets up some symlinks and such in /bin so that you can still call it.
It's actually quite a spiffy idea, though I haven't actually tried it. (A friend did try the package manager on another system since we wanted a package manager that doesn't require root (*remarkably* hard to find actually -- all of the major ones seem to require it; being able to install programs as non-root is one place where Windows actually wins quit a bit at, since it's usually possible, while on Linux you're thrown back into the days before package managers when you had to go through the bitch of resolving dependencies manually) without much luck, but that might have just been the weird quirks of what we were trying to do instead of anything in GoboLinux itself.)
Are you sure it was the application writer's bad practices that forced many apps to require admin privileges? Because the phenomenon of having to run most day to day apps as an admin seems to be limited to Windows.
It's a mix of blame. On one hand, there are (and have been) plenty of programs out there that don't require admin rights, and there have been for a long time. We used several on NT 4 boxes back when I was in school. So it's not like MS has made it impossible to develop them, or even much harder than it would be to develop a non-root program on Unix.
The part that MS does have some blame for is the long history of not even trying to encourage the practice. 95 didn't really have any security to speak of, and a lot of programs just targeted that platform. (Games come to mind here.) Even on NT, by default I think users had admin rights. Because almost everyone ran as admin anyway, there was little need to write your program to support limited users, which meant that app developers didn't do it.
(Damn it, this firefox extension I have will occasionally cause focus to jump around, and it just happened to jump to the submit button before I was done. Advice: if you use Hit-A-Hint or its successor, LOL -- otherwise awesome BTW -- don't set 'space' to be one of the magic keys.)
Anyway:
How 'bout pre OS X? I mean, OS X is only, what, 10 years old? That's less than half the age of many programs that will still run.
Finally, I have all kinds of DOS or windows 3.11 apps that don't run well or at all on windows any more, even in emulation mode.
There are plenty of ones that don't run, but there are plenty that do, and "runs some" is better than almost any other platform's binary compatibility if you look at the time frame of the early 90s.
(Though if you want to see serious backwards compatibility, IBM's highest-end mainframes, the zSeries, still run System/370 binaries from the early 70s.)
Just to play devil's advocate, linux runs any X11 app and that goes back decades and decades (e.g., nethack is from 1985).
If you recompile it. I would be astounded if you could take a nethack binary from before Linux was invented and run it on Linux.
By contrast, there are DOS programs older than Nethack that still run under 32-bit Vista. Binaries.
Also, often apps that runs on OS X can run on any version of OS X but there were some changes between point releases but I don't know of an app that fails to run on new versions.
How 'bout pre OS X? I mean, OS X is only, what, 10 years old? That's less
Wine is an (unofficial) implementation of the Win32 API.
So are the shims.
The whole reason shims exist is because the APIs change over time, so what was correct usage in Win2000 or WinXP might not be correct in Vista or 7.
Well, depending on how you interpret that statement, that's only part of the reason, because MS rarely breaks an API in a backwards-incompatible way.
There are basically two reasons why software stops working on windows:
1.) It makes assumptions that are at a higher level than what the API does. For instance, that the user is running as administrator. At least on the NT line, it has never been the case that the API has "allowed" a program to assume that a requested access to HKEY_LOCAL_MACHINE will succeed, or that it can write to Program Files. (Starcraft crashes at the end of a game when run as a limited user under XP -- presumably because it tries to write LastReplay to Program Files.) Even if the API can theoretically return an 'access denied' error, the programmer assumes that it won't actually arise in practice.
Another example of this is DOS programs that assume they can access the hardware directly and stuff like that, which "of course" doesn't work under NT.
2.) It makes assumptions that are not part of the API proper, but just artifacts of the implementation. For instance, assuming HANDLEs (which the API says should be opaque) are pointers which can be directly accessed (which is true in version A but not true in version B). One good example of how subtle this can be is a shell namespace extension that implemented a function signature wrong by giving the wrong number of arguments. This creates the strong potential for stack corruption. On Windows 95 and NT 4, it worked because Windows was compiled with frame pointers, which left it robust to that error. With Windows 2000, Windows was compiled with the frame pointer optimization, which meant that program crashed Explorer. At no point was "Windows will be compiled with frame pointers" part of the API.
(Then there are higher level problems of a similar nature. There are programs that will open up the display properties dialog then send tab messages or otherwise enumerate the controls present, then change, say, the fifth control so it has the setting they want. What if MS changes the tab order or adds a new control? Boom.)
So if you say that "the APIs change over time" means that their defined behavior changes, this is the decidedly minor aspect of compatibility problems. It's only if you allow implementation-specific details to creep in (which I don't consider part of the API) that your statement is true.
The line between humor and seriousness can be very thin at times.
One of my favorite quotes about gay marriage was said by Jon Stewart during an interview of him, which was something like "At first I was really against it. Because I love my wife. And then I realized that it wouldn't be mandatory."
Let me introduce to my friend, the dictionary. You might find it enlightening.
Think about it: What does a politician or government agency benefit by people feeling more secure?
They can say "look how much safer you've become under my watch. Vote for me again!"
Cut the power, seriously? Cuz there's nothing safer than suddenly losing engine power at 150 kph. Power steering, breaks, manouverability- all go out the window.
Yeah, good thing that doesn't happen.
(I know, the summary didn't convey that very well.)
Also, why use GPS for this? That's a surefire way to introduce errors into the system. Why not just hook into the cars existing speedometer?
That's a good idea. But the speedometer would need to know what the current speed limit is so it knows what to limit to. I know, maybe we could put a network of satellites in orbit from which we could derive our position, figure out what road is at that position, then look up the limit in some database.
FTFA, looks like what it allows is arbitrary execution of Java code. So it wouldn't be architecture-specific at all, unless you started using architecture-specific stuff in said code. If you've got the JVM to exploit, then you've got the JVM to run stuff on.
That would probably completely invalidate the results though, for two reasons. First, the sorts of people who would opt into that wouldn't at all be representative. (It would take an unusual person to even find the opt-in, let alone volunteer for a degraded experience knowingly.) Second, knowing about it would be way too likely to affect how the people behaved.
You could get halfway by saying "would you like to help us do research" or something like that, without saying in what way, which would reduce these problems, but not completely.
I can definitely buy that something like that helps with the individual commits thing (I didn't see it *explicitly* listed as a feature, but it wouldn't be all that hard to add once you have repository browsing support (which is listed as a feature of Meld), but I fail to see at all how that helps with the first problem, since you're still looking at the Tex source.
...it lacks much of the power of a full SCM.
I'm going to start off by saying that good interaction with version control is, I think, the single biggest benefit Latex offers over Word for the sorts of things that I do, at least pre-submission time. (This is probably partly borne out of a overly enthusiastic perspective on version control, but it's definitely up there.)
That said: track changes does have a few benefits over SCM use. First, it's much more user friendly if you are reading to see what's changed. (Ironically, this is most important when you have collaborators, which is when VCSs shine brightest.) SCMs will give you diffs, but it's diffs of the Tex source code. I don't know about you, but I really don't like trying to read that, especially if some misguided soul hit meta-q and changed the line breaks. An alternative is to use something like latexdiff, which overall is pretty awesome, but can be kind of clunky to use and, in my experience, has often needed a few manual changes to the output before the result compiles.
Second, track changes doesn't just show you what changed or give you a way to accept or reject a full revision, which VCSs make easy, but gives you much finer-grained control on what specific changes to accept or reject. You can cherry-pick changes; this sentence's changes are good, this sentence's changes are bad. To get the same effect with a version control solution you would need to save and commit after every individual changes to the document. I make pretty fine-grained commits, and even I am a long way away from that level.
And, more importantly, does it nicely support semantic markup and allow the user to extend the semantic definitions?
Word has long (that is, decades long) supported what I would call semantic markup, even if it's more hidden than the bold/italic/underline/font size buttons on the toolbar. You can make your own styles that inherit from existing styles, and stuff like that.
You can't do programming in the same sense as Tex (at least not without macros, and I don't know if they do anything like what you'd want) so it is more restrictive, but Word is much closer to the content/presentation separation model than many Tex-heads give it credit for, at least if you use it that way.
Word's biggest shortfalling in this sense is that it's easier to do it the wrong way than it is to do it the right way, where it's usually the other way around in Tex.
Does it nicely typeset source code and algorithm descriptions?
You could, though the problem here is that it's much more tedious to do any sort of syntax highlighting. In Latex, at least depending on the package you're using, you can just toss a \ before any keywords or whatever in your code, while I don't know of any good way of doing the same in Word.