Unfortunately for you and MS, the core DLLs at the root of many of "IE"'s vulnerabilities are actually "core" pieces of the OS and can and are, in fact, exercised by other applications as well. "Uninstalling" IE, or never installing it, still results in an OS with these DLLs in place.
That depends on what you mean by "the OS". As far as I'm concerned, IE is less a part of "the OS" than, say, KDE or Gnome is on Linux (or at least Qt and GTK). At least one of libraries are more core to 99% of Linux users than the IE DLLs are to Windows users.
The rest of your post is a bit of a red herring; I made no statement regarding the overall security model of Windows.
Standing still might be just as bad as or worse than sitting still.
I doubt it, for the reason I stated. But also, being already standing makes it much easier to have other little motions. If you get stumped, you can pace back and forth for a minute instead of lean back in your chair and look at the ceiling. (Your habits may vary.:-))
Except that the Windows command line, and MS focus on it, has improved massively (out of all recognition really) in the last 2 or 3 years.
You're definitely true. I'll be the first to say that, for instance, the PowerShell object-piping thing is a really neat and useful idea.
But, IMO, it's still far from what you see on a Unix-like platform in terms of actual usability. I mean, even the terminal emulator that hosts both CMD and PowerShell is still a huge turd. I mean, even in Win7, you can't even resize the damn window (in ways that matter) without going into a dialog box and changing the width field. Then there's a bug through XP (seems to be fixed in Windows 7) that causes it to ignore (most of the time) my keyboard layout changes.)
Then you get to things with the shell itself. For instance, the fact that the tab completion behaves differently from Unix isn't a problem on it's face, but having used both variants extensively (I don't usually use Cygwin shells when in Windows; I take a pretty strong "when in Rome" approach to that), I much prefer the Unix-shell version. (The CMD/PowerShell tab completion method, while sometimes handy, has two significant problems: unless you know your directory contents really well, it's not very predictable. Second, the worst-case behavior is terrible. There are some other minor issues like not being able to tab complete something in the middle of a command without it wiping out everything that follows, and not tab completing through a forward slash despite most commands and programs accepting them. PowerShell doesn't have that very last problem.) Another thing I miss a ton is ctrl-R, for reverse incremental search. F8 does something similar in CMD, but... it doesn't seem to work very well for some reason. It doesn't seem to work at all in PowerShell.
Disclaimer: I've played with PowerShell a little bit, but only a little bit. It looks like you can do things like customize the tab completion behavior, so it's possible that some of my concerns could be alleviated.
(Finally, believe me, I'm no "rah rah Unix/Linux" person; I've been called a MS shill on a couple of occasions. You say "age old Unix story of stagnation through fragmentation", which I don't quite agree with, but I do feel that there are a lot of people out there who believe that almost everything Unix does it does right, that the autotools really aren't that bad, that it's actually a reasonable decision to use 'make' for a C project, etc. is a big problem, and that they can be as prominent as they are is holding back Linux. I'm very sympathetic to parts this presentation (now a decade old) by Rob Pike, where he says that systems research is hurting because people get set in an orthodoxy. (See pp. 14, 16, 17.) (And if you look at his credentials, he's not exactly a MS shill either.) In my opinion, Windows actually serves a very very valuable purpose -- it's the only OS in even moderately wide use that isn't backed by Unix. The fact that they do things differently is, in and of itself, valuable -- even if they don't always get it right. (Because, IMO, they do get right in ways that Linux/Unix doesn't as much as they get it wrong.) I take the position of disliking every OS out there pretty strongly, just in different ways.)
It could also be the other way round - on Unix you have the command line heritage, but also it's much more of a pain to create a GUI, so even if you start out thinking "this tool should have/be a GUI", you may end up with command line.
It's possible, though I would still say that, in most cases, it probably more has something to do with the mindset.
I suspect it's more that both hold because of the different mindset that each platform engenders. The Windows command line is mostly crap because the attitude in the Windows world is mostly that it's unimportant, because GUIs can accomplish the same thing. And that attitude leads people to make advanced GUIs.
In other words, it's the same thinking of "we should do this in a GUI" that leads to both situations, not someone sitting down and thinking "I want to write this as a command line tool, but that'll make it a pain to use, so I'll write a GUI instead."
That's not really true most of the time, from what I understand. The little I've seen said that the increased memory use and cache pressure that's caused by 64-bit pointers is canceled out by the increased register set of x86-64.
I don't know how one might solve these issues outside of making programming a full-body sport,...
One suggestion that might help is some sort of standing desk. I used to use my laptop like this: I have a 5-drawer filing cabinet, and if I put my laptop on top of it, it was a comfortable height for the screen. If I put the keyboard on top of one of the drawers, it was an acceptable height to type at, so I just did it that way. Even if you're not moving a whole lot more, the simple fact you're standing means, I suspect, that your muscles are working more to keep you upright.
The problem is that it's probably hard to find a standing desk of the right height, because the "right" height will vary much more from person-to-person than the right height of a standard desk.
I believe the way copyrights work on fonts is as follows: a particular font file can be copyrighted but the shape of the glyphs can't. So you could take screenshots of every letter at each size and distribute those bitmaps as a new font; take them and make your own glyphs based on them, etc., but you can't just email consolas.ttf (or whatever the heck file type fonts come in nowadays) to your buddy.
Thus most pros shoot in raw, as you can image PhotoShop, Lightroom, Aperture and others can do a much better job than the built-in processor.
IMO, the conversion from RAW -> JPEG being done better than on the camera chip is by far the least compelling reason to shoot RAW, especially with Canons (where the on-camera processor already does a really job). 99% of people would never be able to tell the difference between the two processing options, even on a properly calibrated screen.
The real reason to shoot RAW is the world of post-processing options that shooting RAW presents you. Because of the 12 bits of color depth you have more latitude with playing with the exposure controls; if you make sure that you don't overexpose anything (i.e. you "expose for the highlights") you can compress the dynamic range a bit to bring out more detail in the dark areas. Because white balance hasn't been applied yet, you can change white balance post-processing losslessly. (There's software that will give you white-balance controls over JPEG pictures in a similar manner, but it's lossy.)
Great coverage in US. Every city I've been to has had solid coverage. I've only been to fairly large cities though.
And apparently not Madison, WI. State Capitol with, depending on how you count, between a quarter- and half-million people.. and we just really started to get actual, non-roaming coverage here a couple months ago. Even now, only half the city is not in roaming territory.
Almost everyone's experience, including mine, is strongly biased, but in my experience T-mobile's doesn't hold a candle to AT&T's or Verizon's.
(This is coming from someone who really wished that we had better T-mobile coverage too, and would switch in an instant if they introduced it.)
Always make the rough draft of a program clean and readable.
Not only that, but if the optimized version is much less readable than the initial version, consider keeping and maintaining *both* versions. You can run tests to compare the output of each version, replace the fast, not-obviously-incorrect version with the slow, obviously-not-incorrect version if you hit a bug and see if it's still there, etc.
(MS did or does this with Excel; at least until recently, and perhaps still, the recomputation engine for the spreadsheet was hand-tuned assembly. However, for testing and development reasons, they also had a much slower, high-level-language version.)
You don't HAVE to touch the same surface you are seeing though.
But not doing so brings all sorts of problems. You need to be able to detect where the fingers are before they're actually touching, or it'll be horribly imprecise... you go and touch the surface, and find out that you clicked an inch off. Alternately, you just have a big fancy multitouch trackpad, which I also don't think will take off.
If you're talking keyboard, you lose the tactile sensation of keys. There's some research on making sort of adaptive surfaces that combine touch sensitivity with more real buttons (a la a fancier Blackberry Storm), but without that this is a losing proposition. Even with it, its still probably won't compare to a real keyboard when it comes to the ability to detect typos simply by touch.
I don't buy it. Touch screens (multitouch or not) by their very nature mean that you're touching the same surface that the image is on. This means that either your arms are raised to a viewing position, your head is tilted down to see a "touching" position -- neither of which is comfortable for long-term use. (Or you compromise and make both a little uncomfortable.)
(Maybe I'm just weird, but I find laptops almost unbearable for long term use because of the same reason.)
Many people don't understand that encrypted data is the SAME SIZE as unencrypted data.
That depends on your encryption algorithm. For instance, some are block-based, which means at the least you have to round up to the nearest block size. I don't know whether SSL fits into this or not.
There's also overhead of setting up the encryption: SSL has a few messages that pass back and forth (to establish the signature is correct) before you even begin the transfer.
Huh? Don't worry, 99.9% of the.x XML stuff is sticking around. It's only one particular, apparently rarely-used feature that is covered by this injunction.
Compensation isn't the only goal of laws; another is determent. To someone who is worth millions, a $200 ticket is much less of a deterrent than to most people, so raising it is not too unreasonable. (That said, without reading TFA, a quarter million dollars is almost certainly excessive.)
(There's also punishment, but (1) I don't subscribe to that being a particularly important goal of laws, and (2) the same argument works there as in the deterrent case.)
Responsible Disclosure is like "pro choice" or "pro life". It is a deliberately positive term for purely demagogic reasons. You can't be for irresponsible disclosure, just like you can't be against choice or against life.
I sometimes wonder if anything would have been different if, before the Iraq invasion, the sides were commonly known as the "pro-peace" and "anti-peace" positions.
Or do all these complaints about Firefox==slow|unstable|whatever come from Windows users? In which case, I would suspect something else is wrong, because the Linux and OS X versions have been rock solid for me.
I can't shift the blame off Flash, but I've also experienced the "Firefox freezes for a couple seconds" stuff on both Windows and Linux. For Windows I just have the official build; for Linux I can't say as I didn't install it. The Linux version definitely had more of a problem with that.
(I also had to restart FF on Linux once or twice a day if I was using it for Pandora because the sound would get garbled after a while. I blame that on Flash though.)
The following program does not contain any explicit calls to CreateThread and registers as 1 thread in task manager. It seems to work; clicking anywhere in a window will minimize it.
Both windows in this program are created equivalently; neither one should be more "top-level" than the other. Both show up in the task bar.
Compile with 'cl blah.cpp user32.lib'; I'm using the version that came with VS2008 Pro.
Sorry, didn't realize I wrote so much. Here's the tl;dr version:
I'm pretty sure that all or almost all major GUI programming frameworks proceed by handling one event at a time. An event isn't handled until the previous one is done being handled. This is all done in a single thread.
Slashdot Mirror
Unfortunately for you and MS, the core DLLs at the root of many of "IE"'s vulnerabilities are actually "core" pieces of the OS and can and are, in fact, exercised by other applications as well. "Uninstalling" IE, or never installing it, still results in an OS with these DLLs in place.
That depends on what you mean by "the OS". As far as I'm concerned, IE is less a part of "the OS" than, say, KDE or Gnome is on Linux (or at least Qt and GTK). At least one of libraries are more core to 99% of Linux users than the IE DLLs are to Windows users.
The rest of your post is a bit of a red herring; I made no statement regarding the overall security model of Windows.
Standing still might be just as bad as or worse than sitting still.
I doubt it, for the reason I stated. But also, being already standing makes it much easier to have other little motions. If you get stumped, you can pace back and forth for a minute instead of lean back in your chair and look at the ceiling. (Your habits may vary. :-))
Except that the Windows command line, and MS focus on it, has improved massively (out of all recognition really) in the last 2 or 3 years.
You're definitely true. I'll be the first to say that, for instance, the PowerShell object-piping thing is a really neat and useful idea.
But, IMO, it's still far from what you see on a Unix-like platform in terms of actual usability. I mean, even the terminal emulator that hosts both CMD and PowerShell is still a huge turd. I mean, even in Win7, you can't even resize the damn window (in ways that matter) without going into a dialog box and changing the width field. Then there's a bug through XP (seems to be fixed in Windows 7) that causes it to ignore (most of the time) my keyboard layout changes.)
Then you get to things with the shell itself. For instance, the fact that the tab completion behaves differently from Unix isn't a problem on it's face, but having used both variants extensively (I don't usually use Cygwin shells when in Windows; I take a pretty strong "when in Rome" approach to that), I much prefer the Unix-shell version. (The CMD/PowerShell tab completion method, while sometimes handy, has two significant problems: unless you know your directory contents really well, it's not very predictable. Second, the worst-case behavior is terrible. There are some other minor issues like not being able to tab complete something in the middle of a command without it wiping out everything that follows, and not tab completing through a forward slash despite most commands and programs accepting them. PowerShell doesn't have that very last problem.) Another thing I miss a ton is ctrl-R, for reverse incremental search. F8 does something similar in CMD, but... it doesn't seem to work very well for some reason. It doesn't seem to work at all in PowerShell.
Disclaimer: I've played with PowerShell a little bit, but only a little bit. It looks like you can do things like customize the tab completion behavior, so it's possible that some of my concerns could be alleviated.
(Finally, believe me, I'm no "rah rah Unix/Linux" person; I've been called a MS shill on a couple of occasions. You say "age old Unix story of stagnation through fragmentation", which I don't quite agree with, but I do feel that there are a lot of people out there who believe that almost everything Unix does it does right, that the autotools really aren't that bad, that it's actually a reasonable decision to use 'make' for a C project, etc. is a big problem, and that they can be as prominent as they are is holding back Linux. I'm very sympathetic to parts this presentation (now a decade old) by Rob Pike, where he says that systems research is hurting because people get set in an orthodoxy. (See pp. 14, 16, 17.) (And if you look at his credentials, he's not exactly a MS shill either.) In my opinion, Windows actually serves a very very valuable purpose -- it's the only OS in even moderately wide use that isn't backed by Unix. The fact that they do things differently is, in and of itself, valuable -- even if they don't always get it right. (Because, IMO, they do get right in ways that Linux/Unix doesn't as much as they get it wrong.) I take the position of disliking every OS out there pretty strongly, just in different ways.)
It could also be the other way round - on Unix you have the command line heritage, but also it's much more of a pain to create a GUI, so even if you start out thinking "this tool should have/be a GUI", you may end up with command line.
It's possible, though I would still say that, in most cases, it probably more has something to do with the mindset.
So as we wouldn't count a problem with notepad as a Windows OS issue, so we shouldn't count ones for other OS's non-essential programs.
Not saying you're in this group, but a lot of people around here have no problem counting IE vulnerabilities against Windows.
I suspect it's more that both hold because of the different mindset that each platform engenders. The Windows command line is mostly crap because the attitude in the Windows world is mostly that it's unimportant, because GUIs can accomplish the same thing. And that attitude leads people to make advanced GUIs.
In other words, it's the same thinking of "we should do this in a GUI" that leads to both situations, not someone sitting down and thinking "I want to write this as a command line tool, but that'll make it a pain to use, so I'll write a GUI instead."
...64 bit will be slower.
That's not really true most of the time, from what I understand. The little I've seen said that the increased memory use and cache pressure that's caused by 64-bit pointers is canceled out by the increased register set of x86-64.
I don't know how one might solve these issues outside of making programming a full-body sport, ...
One suggestion that might help is some sort of standing desk. I used to use my laptop like this: I have a 5-drawer filing cabinet, and if I put my laptop on top of it, it was a comfortable height for the screen. If I put the keyboard on top of one of the drawers, it was an acceptable height to type at, so I just did it that way. Even if you're not moving a whole lot more, the simple fact you're standing means, I suspect, that your muscles are working more to keep you upright.
The problem is that it's probably hard to find a standing desk of the right height, because the "right" height will vary much more from person-to-person than the right height of a standard desk.
I believe the way copyrights work on fonts is as follows: a particular font file can be copyrighted but the shape of the glyphs can't. So you could take screenshots of every letter at each size and distribute those bitmaps as a new font; take them and make your own glyphs based on them, etc., but you can't just email consolas.ttf (or whatever the heck file type fonts come in nowadays) to your buddy.
The problem isn't "0O" differentiation. It's trying to figure out if that one char 'O' is a zero or an "O."
You say toe-may-toe, I say toe-ma-toe.
And if anyone uses "O" as a variable (/constant) name they deserve to be executed, regardless of font. :-)
Thus most pros shoot in raw, as you can image PhotoShop, Lightroom, Aperture and others can do a much better job than the built-in processor.
IMO, the conversion from RAW -> JPEG being done better than on the camera chip is by far the least compelling reason to shoot RAW, especially with Canons (where the on-camera processor already does a really job). 99% of people would never be able to tell the difference between the two processing options, even on a properly calibrated screen.
The real reason to shoot RAW is the world of post-processing options that shooting RAW presents you. Because of the 12 bits of color depth you have more latitude with playing with the exposure controls; if you make sure that you don't overexpose anything (i.e. you "expose for the highlights") you can compress the dynamic range a bit to bring out more detail in the dark areas. Because white balance hasn't been applied yet, you can change white balance post-processing losslessly. (There's software that will give you white-balance controls over JPEG pictures in a similar manner, but it's lossy.)
Great coverage in US. Every city I've been to has had solid coverage. I've only been to fairly large cities though.
And apparently not Madison, WI. State Capitol with, depending on how you count, between a quarter- and half-million people.. and we just really started to get actual, non-roaming coverage here a couple months ago. Even now, only half the city is not in roaming territory.
Almost everyone's experience, including mine, is strongly biased, but in my experience T-mobile's doesn't hold a candle to AT&T's or Verizon's.
(This is coming from someone who really wished that we had better T-mobile coverage too, and would switch in an instant if they introduced it.)
Always make the rough draft of a program clean and readable.
Not only that, but if the optimized version is much less readable than the initial version, consider keeping and maintaining *both* versions. You can run tests to compare the output of each version, replace the fast, not-obviously-incorrect version with the slow, obviously-not-incorrect version if you hit a bug and see if it's still there, etc.
(MS did or does this with Excel; at least until recently, and perhaps still, the recomputation engine for the spreadsheet was hand-tuned assembly. However, for testing and development reasons, they also had a much slower, high-level-language version.)
You don't HAVE to touch the same surface you are seeing though.
But not doing so brings all sorts of problems. You need to be able to detect where the fingers are before they're actually touching, or it'll be horribly imprecise... you go and touch the surface, and find out that you clicked an inch off. Alternately, you just have a big fancy multitouch trackpad, which I also don't think will take off.
If you're talking keyboard, you lose the tactile sensation of keys. There's some research on making sort of adaptive surfaces that combine touch sensitivity with more real buttons (a la a fancier Blackberry Storm), but without that this is a losing proposition. Even with it, its still probably won't compare to a real keyboard when it comes to the ability to detect typos simply by touch.
I believe Multi-touch will be
I don't buy it. Touch screens (multitouch or not) by their very nature mean that you're touching the same surface that the image is on. This means that either your arms are raised to a viewing position, your head is tilted down to see a "touching" position -- neither of which is comfortable for long-term use. (Or you compromise and make both a little uncomfortable.)
(Maybe I'm just weird, but I find laptops almost unbearable for long term use because of the same reason.)
Many people don't understand that encrypted data is the SAME SIZE as unencrypted data.
That depends on your encryption algorithm. For instance, some are block-based, which means at the least you have to round up to the nearest block size. I don't know whether SSL fits into this or not.
There's also overhead of setting up the encryption: SSL has a few messages that pass back and forth (to establish the signature is correct) before you even begin the transfer.
- Retrieve a crab/lobstrer pot ?
- Retrieve a Man Overboard ?
- Fetch a gill net ?
- Meet with a sister ship during a seine net operation ?
I can't speak to the first three, though I suspect 200m is pretty good there, but the last one? Definitely.
(That is 200 meters, or barely over 650 ft, not 200 miles.)
How can it be excessive?
Easy: if the proportion is too high.
And don't believe me? The older, non-XML formats haven't been updated to include Office 2007 features. This is especially apparent in PowerPoint.
Huh? Don't worry, 99.9% of the .x XML stuff is sticking around. It's only one particular, apparently rarely-used feature that is covered by this injunction.
Compensation isn't the only goal of laws; another is determent. To someone who is worth millions, a $200 ticket is much less of a deterrent than to most people, so raising it is not too unreasonable. (That said, without reading TFA, a quarter million dollars is almost certainly excessive.)
(There's also punishment, but (1) I don't subscribe to that being a particularly important goal of laws, and (2) the same argument works there as in the deterrent case.)
Responsible Disclosure is like "pro choice" or "pro life". It is a deliberately positive term for purely demagogic reasons. You can't be for irresponsible disclosure, just like you can't be against choice or against life.
I sometimes wonder if anything would have been different if, before the Iraq invasion, the sides were commonly known as the "pro-peace" and "anti-peace" positions.
I don't have points at the moment, but well done.
Or do all these complaints about Firefox==slow|unstable|whatever come from Windows users? In which case, I would suspect something else is wrong, because the Linux and OS X versions have been rock solid for me.
I can't shift the blame off Flash, but I've also experienced the "Firefox freezes for a couple seconds" stuff on both Windows and Linux. For Windows I just have the official build; for Linux I can't say as I didn't install it. The Linux version definitely had more of a problem with that.
(I also had to restart FF on Linux once or twice a day if I was using it for Pandora because the sound would get garbled after a while. I blame that on Flash though.)
Windows needs a thread for every top level window
Yeah, you're wrong.
The following program does not contain any explicit calls to CreateThread and registers as 1 thread in task manager. It seems to work; clicking anywhere in a window will minimize it.
Both windows in this program are created equivalently; neither one should be more "top-level" than the other. Both show up in the task bar.
Compile with 'cl blah.cpp user32.lib'; I'm using the version that came with VS2008 Pro.
Sorry, didn't realize I wrote so much. Here's the tl;dr version:
I'm pretty sure that all or almost all major GUI programming frameworks proceed by handling one event at a time. An event isn't handled until the previous one is done being handled. This is all done in a single thread.