And more importantly, why do they require a minimum top speed of 100 MPH? 80 MPH would be more than sufficient for 99.99% of roads worldwide. I'd be happy with 100 MPG even if I could never get it over 75 MPH.
As others have said, you want to be able to go 70 when going uphill too. One of my friends had an old junker when we were undergrads that could easily maintain highway speeds on flat roads (we were definitely in the 70s at times) but whenever she would come back to school, approaching the town you have to go over a ridge in the Appalachians. She could hit the bottom of the ridge going 70, keep the pedal floored, and be going 45 or 50 at the top. This isn't some back road either; it's the main route into PSU from the south-east, and is a four-lane segment of US-322.
Requiring 100 mph is probably a simple way of trying to prevent something like that from happening.
...Ohio during the day (was it Ohio that has unrestricted speed limits during the day - or have they revoked that rule already!).
As someone who has driven across Ohio on I-80 on a couple of occasions, it at least isn't the case on that road, much to my chagrin. (It's something like 4 hours across it at 65 mph, which is over a third of the time from my current home to my parents'.
Perhaps the error was on Mr. Felton's side... what method did he use to count the votes?
He used the "look at the vote totals the machine printed" method.
Seriously, it has a picture of them. Did you RTFA and somehow didn't notice it, or do you like making uninformed comments? (Okay, that is a bit inflammatory. The first time I went to TFA, the pictures didn't load. But it still says in the text.)
Version control, as is done with code, should be done on a content management server in an office environment.
Which works really well when you don't have something that formal set up and are just emailing documents around.
Anyway, dropping DOC files into SVN or something wouldn't work at all, since the diffs wouldn't be human-readable. (Those for ODT wouldn't be much better.) Code works well because it's plain text; the facilities available for doing the same for Word more or less don't exist.
Besides, the track changes feature gives you something which even SVN + a smart DOC diff program wouldn't, which is the ability to easily accept and reject individual changes. You could of course include this ability (there are some graphical diff programs that let you do it essentially, though I don't know any that will let you see changes from many sources highlighted based upon who made the change) in the diff program or the word processor itself, but they currently aren't.
Word's approach may not be ideal, but it works reasonably well in practice, and OO isn't trying to improve on the idea.
Any statements in the documentation that start out "Don't" or marked "Warning" or "Notice" are always present because of flaws -- the right approach is to fix the software (and remove the statement from the documentation).
So if the documentation says "Warning: Once a file is deleted from the recycle bin, it is impossible to recover" that shows that there is a flaw in the software?
At least open office 2.0 didn't really support that...
It does, but not nearly as well as Word. For instance, I'm not sure how well it handles tracking edits by multiple people, and I do know that deleted text shows up in the original place, just strike through, which probably throws off the pagination. Word displays deleted text in the margin, like the new notes feature. I was excited when I read that because I expected OO Writer to follow suit, but according to the article, that's not yet. Still, the notes in the margin seems like the fist step there, so hopefully better track changes support is not far behind. Here is another issue with the track changes feature that I had forgotten about.
(This is a feature I use myself a fair amount, and have been disappointed with OO's support for it.)
I also have a couple votes for this improvement, which is to add something like Word's normal mode. Having the margins there I think is really obnoxious. Normal mode in Word will make it so that successive lines aren't a couple inches apart on the screen. Even Word's page view mode lets you collapse the top and bottom margins.
There aren't major issues with OO Writer, but at the same time, there are enough minor annoyances that I'll still take Word in a second.
(Calc vs. Excel is another matter... I go back and forth there. Excel has a bunch of annoyances too...)
Windows doesn't have signals as such, so I'm going to say not really. It might affect the POSIX subsystem and perhaps even Cygwin, but not almost certainly not "native" Windows apps.
The chances that Microsoft would allow Firefox to integrate itself with the OS in the same way IE is integrated are... well, it's not going to happen.
I'll bite. In Vista or Server 2008, the latest versions of the consumer and server product lines, in what way is IE integrated with the rest of the OS?
Vista even separated the MSHTML component from Explorer. If you type a web address into Windows Explorer, it doesn't reuse the window like it does in XP, it opens it in your preferred web browser. (I think... I think it doesn't just use IE. I don't have a Vista computer handy though so can't check.) If you type a local path into IE, it opens a new Explorer window.
Even in XP, the ties between IE and Explorer are often overstated.
Maybe this is why they aren't able to give away decent developer tools, standardized antivirus, or a decent package management system.
Package management system and antivirus I can give you, but developer tools? Ever used Visual Studio Express Editions? IMHO they're better than anything that you can get for Linux, with the very notable exception of Eclipse while working with Java. (But I don't like Java, so that doesn't count.:-)) How 'bout their debuggers, which are probably more powerful than GDB? Or the.Net framework, which comes with compilers? Or the DDK, which also comes with a build system that can be used for applications (and some people do use it for such)?
Their tools aren't perfect, but if I were to pick a development environment for C++ between what I can get from MS and what I can get from your standard Linux distro, I would go with the former in an instant.
Yes. On the other hand, it's not unthinkable that there could be a compatibility layer to the Windows API if MS were to turn around and want to use it (which they won't, at least for a very long time). Mach also presents a very different interface, but it speaks POSIX because there is a Unix subsystem.
Then why not give users the choice? Why not let me check a box that says "Yes,I know that using this driver will not allow me to use DRM media-run it anyway"
This is already the case in 32-bit Vista; loading unsigned drivers is possible, but it disables the DRM mechanisms.
I don't think this is true in x64 though, which is a shame.
The driver can issue instructions that aren't valid from user mode, so you would need either some sort of software translation to ensure that this doesn't happen (like the way VMWare handles kernel code), or the ability to trap and emulate (which is hard on x86). At this point it's more like the user mode portion is a VM than just a set of entry points to places in the current OS. (This even assumes that the functions map easily between the versions, which isn't a sure thing, especially in the case of the audio drivers, which by my understanding have been substantially reworked.)
Would it have sold enough copies for it have been worth it for MS to put the engineering into it? I don't know. But it's entirely possible the answer is no. In any case, HW compatibility is one of only many things people complained about, so I doubt it would have been lessened all that much. (In fact, given how much criticism was coming from people running on underpowered (by Vista's enlarged standards) machines, people with older machines trying to run it could have even hurt.)
I was going to post "wait, IE existed before version 4?", but then I realized that I'm pretty sure I've used IE 2.
Damn you for making me dredge up that painful, painful memory.
(Also, you're forgetting that there was also IE 5.5 in there at least, and according to wikipedia, 4.5. So more like... 9th try is the charm. Which hey, has three as a factor.)
It's an ATI TV Wonder Elite; it's driven by the Theatre 550 chip.
I did give some thought to Linux compatibility when I got it, but the card was pretty new when I got it, so I figured there just wasn't time for people to reverse it yet, and I expected a few months to go by and it would be working. Oh well.
It may be, but for video cards, it's more likely the driver. Crashes caused by the video card drivers accounted for at least a sizable minority, and perhaps even a majority of XP crashes reported to MS through the crash reporting mechanism.
They still run in the kernel in Vista; I'm not sure how that jibes with Wampus's comment above about it restarting the driver. Audio drivers, however, are moving into userspace.
It isn't supported, at least last I looked. I chose the card because it had the best quality in the price range at the time of purchase.
And yes, I blame ATI. However, whoever's fault it is doesn't change the fact that I can't use my TV tuner in Linux. I don't really use it anymore anyway, but for quite some time this was actually a very annoying thing.
You can always provide some sort of compatability environment for drivers. There is no reason why they did not provide an XP driver support mechanism.
Um, besides it's extra engineering that they have to do. And given the types of drivers they are talking about -- e.g. audio drivers, which ran in the kernel in XP but are now largely pushed into userspace in Vista -- a good bit of engineering.
Yes, ndiswrapper exists. However, if it's so reasonable to expect MS to provide a compatibility layer, where are the wrappers for other kinds of drivers? Where's the wrapper that lets me run my TV Tuner card in Linux?
How many of you haven't done regrettable shit when you were 17?
I did regrettable shit as a kid, but none of it put peoples' lives in danger. None of it carried the substantial risk of property damage which the target would have to pay. None if it could have resulted in someone being arrested, even long enough for the cops to find out.
Unfortunately it is nowhere near that simple. *something* has to copy the file, for instance the file system that is on the receiving end of your "copy" system call. If it does not know about extended attributes, you lose.
Yes, but this only needs done once per file system, which isn't bad at all. And it should already be done or I'm even more dismayed at the current state of support. (I don't have a Linux box to test it there, but on Windows, extended attributes are indeed copied, assuming you are going NTFS->NTFS.)
That is the only safe way to make a backup. A copy might fail. I suppose you could rename to the ~ file, then copy to the new file (with the copy-file api) and then write over the new file, and the safety would be equal
You could also copy to the ~ file. (If that fails you likely wouldn't be able to either rename to ~ or create the new file anyway.)
Or you could use something like transactional NTFS, which Vista provides, and avoid the whole shuffling files around problem. Of course, then you cease to be portable, even to previous versions of Windows.
(I also wonder if transactional NTFS was added to help with the case if transactional memory becomes common in a few years, because reversing I/O is one of the major problems with it.)
Without a preserved reference to the original file there is nothing the OS can do.
The file name is almost a preserved reference. You didn't read that link, did you? Ever notice how Windows keeps file creation date in addition to the last modified and last accessed dates? That date is preserved, even when something acts like Emacs. The reason Windows needed this feature is because the long file name also acts like metadata to 16-bit programs... you don't want "c:\some file with long name.txt" to suddenly become "c:\somefi~1.txt" because you opened it in a 16-bit, non-LFN aware program which removed the old file and recreated "c:\somefi~1.txt".
Like I said, it's a huge hack, but it works pretty well. And the same thing could be done with extended attributes.
The second version is what I was proposing.
So you propose rewriting a large portion of our current collection of libraries and applications so that they accommodate extra information as we throw out a large portion of our current file formats? Because that's what the second option was...
Another possibility is to use directories, but change it so that reading a directory produces a data stream that is something like a tar file of all the contents. Writing this to an aware filesystem would produce a matching directory. Writing this to another file system would produce a file that when copied back to the original filesystem would produce the directory. Then all the branches of data is stored in subfiles. Then programs that want to actually use the data rather than copy it would have to open name/data instead of name.
This is probably the best realistic way of handling metadata that still satisfies most of my desires.
It's not perfect because I still can't tell most programs to open just name (instead of name/data) and see just the data, which is one of the benefits of using alternate streams instead of directories in the first place. But it wouldn't be too hard to have applications support it (you may even be able to pick up most of them with a change to the standard OS open dialog, so that it returns name/data instead of name as the chosen file), and having Explorer or your equivalent file browser support it would already be a big step even if the open dialog idea didn't pan out well.
By far the biggest problem is that wide characters cannot represent an arbitrary stream of bytes, for instance an illegal utf-8 encoding. This means that a program cannot rely on uniqueness of a stream of bytes being equivalent to meaning the filename is unique (this is also why case independence is bad and why OS/X decomposed-only utf8 is bad). This leads to nasty security vulnerabilities
Slashdot Mirror
And more importantly, why do they require a minimum top speed of 100 MPH? 80 MPH would be more than sufficient for 99.99% of roads worldwide. I'd be happy with 100 MPG even if I could never get it over 75 MPH.
As others have said, you want to be able to go 70 when going uphill too. One of my friends had an old junker when we were undergrads that could easily maintain highway speeds on flat roads (we were definitely in the 70s at times) but whenever she would come back to school, approaching the town you have to go over a ridge in the Appalachians. She could hit the bottom of the ridge going 70, keep the pedal floored, and be going 45 or 50 at the top. This isn't some back road either; it's the main route into PSU from the south-east, and is a four-lane segment of US-322.
Requiring 100 mph is probably a simple way of trying to prevent something like that from happening.
...Ohio during the day (was it Ohio that has unrestricted speed limits during the day - or have they revoked that rule already!).
As someone who has driven across Ohio on I-80 on a couple of occasions, it at least isn't the case on that road, much to my chagrin. (It's something like 4 hours across it at 65 mph, which is over a third of the time from my current home to my parents'.
Perhaps the error was on Mr. Felton's side... what method did he use to count the votes?
He used the "look at the vote totals the machine printed" method.
Seriously, it has a picture of them. Did you RTFA and somehow didn't notice it, or do you like making uninformed comments? (Okay, that is a bit inflammatory. The first time I went to TFA, the pictures didn't load. But it still says in the text.)
Most traffic accidents are caused by sober drivers.
Most drivers are sober. You should look at the rate of accidents of drunk and sober drivers; I have a suspicion of what you would find.
Version control, as is done with code, should be done on a content management server in an office environment.
Which works really well when you don't have something that formal set up and are just emailing documents around.
Anyway, dropping DOC files into SVN or something wouldn't work at all, since the diffs wouldn't be human-readable. (Those for ODT wouldn't be much better.) Code works well because it's plain text; the facilities available for doing the same for Word more or less don't exist.
Besides, the track changes feature gives you something which even SVN + a smart DOC diff program wouldn't, which is the ability to easily accept and reject individual changes. You could of course include this ability (there are some graphical diff programs that let you do it essentially, though I don't know any that will let you see changes from many sources highlighted based upon who made the change) in the diff program or the word processor itself, but they currently aren't.
Word's approach may not be ideal, but it works reasonably well in practice, and OO isn't trying to improve on the idea.
Any statements in the documentation that start out "Don't" or marked "Warning" or "Notice" are always present because of flaws -- the right approach is to fix the software (and remove the statement from the documentation).
So if the documentation says "Warning: Once a file is deleted from the recycle bin, it is impossible to recover" that shows that there is a flaw in the software?
At least open office 2.0 didn't really support that...
It does, but not nearly as well as Word. For instance, I'm not sure how well it handles tracking edits by multiple people, and I do know that deleted text shows up in the original place, just strike through, which probably throws off the pagination. Word displays deleted text in the margin, like the new notes feature. I was excited when I read that because I expected OO Writer to follow suit, but according to the article, that's not yet. Still, the notes in the margin seems like the fist step there, so hopefully better track changes support is not far behind. Here is another issue with the track changes feature that I had forgotten about.
(This is a feature I use myself a fair amount, and have been disappointed with OO's support for it.)
I also have a couple votes for this improvement, which is to add something like Word's normal mode. Having the margins there I think is really obnoxious. Normal mode in Word will make it so that successive lines aren't a couple inches apart on the screen. Even Word's page view mode lets you collapse the top and bottom margins.
There aren't major issues with OO Writer, but at the same time, there are enough minor annoyances that I'll still take Word in a second.
(Calc vs. Excel is another matter... I go back and forth there. Excel has a bunch of annoyances too...)
Windows doesn't have signals as such, so I'm going to say not really. It might affect the POSIX subsystem and perhaps even Cygwin, but not almost certainly not "native" Windows apps.
This is a lot like the transition from 95 to XP. How many times did Bill Gates declare the "death of DOS" or "16 bit computing"?
The relation between Windows 95 and friends and DOS has always been overstated; that family was decidedly 32-bit.
...mandatory reactivating of Vista every few months...
WTF are you talking about with this one?
The chances that Microsoft would allow Firefox to integrate itself with the OS in the same way IE is integrated are... well, it's not going to happen.
I'll bite. In Vista or Server 2008, the latest versions of the consumer and server product lines, in what way is IE integrated with the rest of the OS?
Vista even separated the MSHTML component from Explorer. If you type a web address into Windows Explorer, it doesn't reuse the window like it does in XP, it opens it in your preferred web browser. (I think... I think it doesn't just use IE. I don't have a Vista computer handy though so can't check.) If you type a local path into IE, it opens a new Explorer window.
Even in XP, the ties between IE and Explorer are often overstated.
Maybe this is why they aren't able to give away decent developer tools, standardized antivirus, or a decent package management system.
:-)) How 'bout their debuggers, which are probably more powerful than GDB? Or the .Net framework, which comes with compilers? Or the DDK, which also comes with a build system that can be used for applications (and some people do use it for such)?
Package management system and antivirus I can give you, but developer tools? Ever used Visual Studio Express Editions? IMHO they're better than anything that you can get for Linux, with the very notable exception of Eclipse while working with Java. (But I don't like Java, so that doesn't count.
Their tools aren't perfect, but if I were to pick a development environment for C++ between what I can get from MS and what I can get from your standard Linux distro, I would go with the former in an instant.
However, do you not agree that if browser X correctly renders the Acid tests, it is more likely to be compliant than if it does not?
We did have an article a bit ago about IE8 passing the Acid2 test.
It's not positive confirmation that they are going all standards compliant, but it can't be bad news.
Yes. On the other hand, it's not unthinkable that there could be a compatibility layer to the Windows API if MS were to turn around and want to use it (which they won't, at least for a very long time). Mach also presents a very different interface, but it speaks POSIX because there is a Unix subsystem.
Then why not give users the choice? Why not let me check a box that says "Yes,I know that using this driver will not allow me to use DRM media-run it anyway"
This is already the case in 32-bit Vista; loading unsigned drivers is possible, but it disables the DRM mechanisms.
I don't think this is true in x64 though, which is a shame.
The driver can issue instructions that aren't valid from user mode, so you would need either some sort of software translation to ensure that this doesn't happen (like the way VMWare handles kernel code), or the ability to trap and emulate (which is hard on x86). At this point it's more like the user mode portion is a VM than just a set of entry points to places in the current OS. (This even assumes that the functions map easily between the versions, which isn't a sure thing, especially in the case of the audio drivers, which by my understanding have been substantially reworked.)
Would it have sold enough copies for it have been worth it for MS to put the engineering into it? I don't know. But it's entirely possible the answer is no. In any case, HW compatibility is one of only many things people complained about, so I doubt it would have been lessened all that much. (In fact, given how much criticism was coming from people running on underpowered (by Vista's enlarged standards) machines, people with older machines trying to run it could have even hurt.)
I was going to post "wait, IE existed before version 4?", but then I realized that I'm pretty sure I've used IE 2.
Damn you for making me dredge up that painful, painful memory.
(Also, you're forgetting that there was also IE 5.5 in there at least, and according to wikipedia, 4.5. So more like... 9th try is the charm. Which hey, has three as a factor.)
It's an ATI TV Wonder Elite; it's driven by the Theatre 550 chip.
I did give some thought to Linux compatibility when I got it, but the card was pretty new when I got it, so I figured there just wasn't time for people to reverse it yet, and I expected a few months to go by and it would be working. Oh well.
It may be, but for video cards, it's more likely the driver. Crashes caused by the video card drivers accounted for at least a sizable minority, and perhaps even a majority of XP crashes reported to MS through the crash reporting mechanism.
They still run in the kernel in Vista; I'm not sure how that jibes with Wampus's comment above about it restarting the driver. Audio drivers, however, are moving into userspace.
It isn't supported, at least last I looked. I chose the card because it had the best quality in the price range at the time of purchase.
And yes, I blame ATI. However, whoever's fault it is doesn't change the fact that I can't use my TV tuner in Linux. I don't really use it anymore anyway, but for quite some time this was actually a very annoying thing.
You can always provide some sort of compatability environment for drivers. There is no reason why they did not provide an XP driver support mechanism.
Um, besides it's extra engineering that they have to do. And given the types of drivers they are talking about -- e.g. audio drivers, which ran in the kernel in XP but are now largely pushed into userspace in Vista -- a good bit of engineering.
Yes, ndiswrapper exists. However, if it's so reasonable to expect MS to provide a compatibility layer, where are the wrappers for other kinds of drivers? Where's the wrapper that lets me run my TV Tuner card in Linux?
How many of you haven't done regrettable shit when you were 17?
I did regrettable shit as a kid, but none of it put peoples' lives in danger. None of it carried the substantial risk of property damage which the target would have to pay. None if it could have resulted in someone being arrested, even long enough for the cops to find out.
The target = the family who is getting busted in on by SWAT, in a dangerous and traumatic fashion, not the local cops.
Unfortunately it is nowhere near that simple. *something* has to copy the file, for instance the file system that is on the receiving end of your "copy" system call. If it does not know about extended attributes, you lose.
Yes, but this only needs done once per file system, which isn't bad at all. And it should already be done or I'm even more dismayed at the current state of support. (I don't have a Linux box to test it there, but on Windows, extended attributes are indeed copied, assuming you are going NTFS->NTFS.)
That is the only safe way to make a backup. A copy might fail. I suppose you could rename to the ~ file, then copy to the new file (with the copy-file api) and then write over the new file, and the safety would be equal
You could also copy to the ~ file. (If that fails you likely wouldn't be able to either rename to ~ or create the new file anyway.)
Or you could use something like transactional NTFS, which Vista provides, and avoid the whole shuffling files around problem. Of course, then you cease to be portable, even to previous versions of Windows.
(I also wonder if transactional NTFS was added to help with the case if transactional memory becomes common in a few years, because reversing I/O is one of the major problems with it.)
Without a preserved reference to the original file there is nothing the OS can do.
The file name is almost a preserved reference. You didn't read that link, did you? Ever notice how Windows keeps file creation date in addition to the last modified and last accessed dates? That date is preserved, even when something acts like Emacs. The reason Windows needed this feature is because the long file name also acts like metadata to 16-bit programs... you don't want "c:\some file with long name.txt" to suddenly become "c:\somefi~1.txt" because you opened it in a 16-bit, non-LFN aware program which removed the old file and recreated "c:\somefi~1.txt".
Like I said, it's a huge hack, but it works pretty well. And the same thing could be done with extended attributes.
The second version is what I was proposing.
So you propose rewriting a large portion of our current collection of libraries and applications so that they accommodate extra information as we throw out a large portion of our current file formats? Because that's what the second option was...
Another possibility is to use directories, but change it so that reading a directory produces a data stream that is something like a tar file of all the contents. Writing this to an aware filesystem would produce a matching directory. Writing this to another file system would produce a file that when copied back to the original filesystem would produce the directory. Then all the branches of data is stored in subfiles. Then programs that want to actually use the data rather than copy it would have to open name/data instead of name.
This is probably the best realistic way of handling metadata that still satisfies most of my desires.
It's not perfect because I still can't tell most programs to open just name (instead of name/data) and see just the data, which is one of the benefits of using alternate streams instead of directories in the first place. But it wouldn't be too hard to have applications support it (you may even be able to pick up most of them with a change to the standard OS open dialog, so that it returns name/data instead of name as the chosen file), and having Explorer or your equivalent file browser support it would already be a big step even if the open dialog idea didn't pan out well.
By far the biggest problem is that wide characters cannot represent an arbitrary stream of bytes, for instance an illegal utf-8 encoding. This means that a program cannot rely on uniqueness of a stream of bytes being equivalent to meaning the filename is unique (this is also why case independence is bad and why OS/X decomposed-only utf8 is bad). This leads to nasty security vulnerabilities