1. Longer lens means more camera shake 2. More camera shake means you need a shorter shutter 3. Shorter shutter means you need to compensate somewhere 4. Compensating means either narrower DoF (if you go with larger aperture) or higher noise (if you go with higher ISO)
Are you going to cite the magical photo fairies next?
I don't think 65 ft is all that unreasonable, but understand that it will make a lot of photography rather harder. Longer lenses mean heavier lenses, which, as you say, means you'll probably need a shorter exposure, at least if hand-held. (Setting up a tripod can often take too long for non-posed photos.) But a shorter shutter means that you'll be compromising somewhere else: narrower depth of field or higher ISO. Narrow DOF can be nice for some artistic shots; less nice for most photojournalism. Sure, these things probably aren't so important if it's nice and sunny out, but what about if it's cloudy? Balancing all of these things can quickly become difficult.
But the real problem is that of perspective. Unless you carry around a 40' self-supporting tower with you, having to stay 65' out means that your angle is going to be MUCH lower. That does two things. First it will make it much easier for your view to be blocked. Instead of walking up to a line of grass and photographing over it, you have to photograph through it. Instead of getting closer and photographing from above the waves, you have to wait until they line up in such a way that nothing's in the way of your shot. It also means a lower angle on the ocean, which may well mean that it's harder to see the oil.
In short, putting a long lens on your camera isn't the same as walking up to something, for a number of reasons, and if you think it is, you should go back to photo school.
Way to mention the results aren't actually statistically significant:
The iPad measured at 6.2% lower reading speed than the printed book, whereas the Kindle measured at 10.7% slower than print. However, the difference between the two devices was not statistically significant because of the data's fairly high variability.
My joke was illustrating a clearly absurd example where modern operating systems do enforce it, so that the reader might ask why it can't do the same for these security features as well.
As has been said many times in this thread, it can. As a user, you can tell Windows to always enforce DEP. Just expect that you may not be able to run all your software, which is why it's not configured that way by default.
MS didn't get where it is by breaking backwards compatibility with a ton of Windows programs, that's for sure.
It can easily be circumvented with a return-to-libc attack.
Hell, it's worse than that: read this 2005 Usenix security conference paper (PDF). It's been a while since I read it, so I can't remember exactly how they did it, but the gist the following. Pretty much all of these attacks require overwriting a return address or function pointer or something like that, so that control transfers to your injected code, to the function in libc that you want to execute (return-to-libc), etc. There are a variety of techniques to detect that sort of thing (especially return address clobbering) with relatively low overhead. The authors of that paper illustrate how you don't even have to do that: just overwriting program data suffices.
Now, that said, I don't not put on my seatbelt when I'm in a car simply because seatbelts don't prevent all deaths (to use an analogy of another poster). As long as people keep using unsafe languages like C, the goal is just going to be reducing the attack surface for even "dumb" attacks like buffer overflows. And DEP does that reasonably well.
Second whoever said 'flash can't do DEP' needs to stop injecting their ignorance into the conversation.
Actually, while I am all for bashing Flash at most opportunities, really the summary/article is right here.
DEP is enabled on a per-process basis. Flash doesn't create its own process, the browser does: therefore Flash has no say in whether it runs with DEP or not.
(In fact, another poster somewhere above says Flash is actually "DEP-clean", so if the browser starts with DEP enabled, Flash won't cause it to bomb.)
In my understanding, "application" means a piece of software with which users interact directly. "Program" means a piece of software in general, even kernels and libraries are programs.
This is a pretty dumb argument because it doesn't matter much, but just for anther perspective, I'm not as "loose" with what "program" means as you are. To me, a "program" is something that the OS can turn into a process -- this makes the program/process distinction but makes the terms very related. That definition excludes the kernel and libraries. (Though to add to the confusion, I might consider the actual code in a library as "program code".)
As for program vs application, that's much more hazy. Something like Word or Firefox is definitely an application; something like Grep probably isn't (though it's definitely a program). "Application" to me means something that 1. the user interacts with (no daemons), 2. is reasonably heavyweight (so no Grep), and 3. is actually doing something the user wants to do, as opposed to a more supporting task (so no window manager).
I'm not saying I'm right or my definitions are better than yours or anything like that, just giving another viewpoint.
Dell stood out because they formalized a real manufacturing process, setup good quality controls, made it brain dead simple to order, and *still* had prices that were just about the best you could get. They had a refined image with organized, glossy ads, which helped a lot.
Not to mention consistently placed in the top couple spots in customer satisfaction surveys.
I haven't payed attention in a decade, but I wonder where they are now...
I didn't post that to say "go police for arresting this kid in this case" (I think authorities are extremely quick to overreact in general), just to point out that dry ice bombs can easily actually do damage.
The other poster is exactly right; I grew up in central PA.
I actually just got done writing a paper and my advisor kept marking "a couple " phrases in it. I actually made an emacs minor mode (based on hi-lock) that highlights a couple of idioms (and Latex mistakes) I need to avoid, and "a couple" followed by something other than "of" was one of them.:-)
While $50 isn't cheap, it's still a fair bit of money for something that is likely a bit of a longshot. From the description it sounds likely to NOT be other Wi-Fi, so a device that looks for Wi-Fi connections isn't the appropriate tool.
I find it amusing that you say "There is no point in encrypting your communication with [UNKNOWN]" and then go on to say "Uh, the more trust the better. It is not black and white."
But it's precisely because trust isn't black-and-white that there can be a point of encrypting your communication with UNKNOWN. If I trust that carrying out a MITM attack is harder than snooping on unencrypted traffic, then there is a point to encrypting without authentication.
News links off of slashdot, forums, imageboards, wikis, none of these need javascript.
News links off of slashdot don't, but with what I get when I'm not signed in, reading comments I think does. Some things in many forums need JavasSript -- spoiler tags for instance, or Fark's quote button. (Sure, you don't need to have that last feature, but it's so useful I'd question your sanity if you regularly participated in discussion there and didn't use it.) On Flickr (not really an imageboard, but still), JavaScript enables a far more usable uploader at least. Dpreview uses a dropdown menu for navigation; without the onselect event, the only way to go to a specific page is by changing the URL or hitting prev/next a bunch.
Just to drive this point home, it's less an hour and a half later, I haven't been browsing the internet, and I've already found a new site that I needed to enable JavaScript for.
My my estimation based on the scroll bar position after counting for a while, I've got about 250 websites listed with site-specific preferences; some of those will just have plugins enabled so I can look at PDFs, but most are to enable JavaScript.
They range from a couple dozen sites that I want to watch some Flash video on (enabling plugins but leaving JS off doesn't seem to work) to online stores (NewEgg and Best Buy both need JS for nearly essential features) to two of my banks (one of which doesn't actually need it I think, but it adds a few neat features; the other I think needs it) to some discussion-centric sites (even/. by default, but also things like Blogspot if you want to add comments) to the social networking sites to sites like this.
I can't say for certain what percentage of the sites I visit I have whitelisted, but rarely does a day go by when I don't discover some new site to add.
What's the problem with input? Are you hinting at the inconvenience of typing text on an iPad? This is trivially taken care of by providing an external keyboard with a dock to conveniently position the screen. Throw in an external display connector, and you're all set.
But how portable is such a setup really? As compared to, say, a Netbook? Could you use it in your lap?
I disagree that they are in the same space... it's close, but not quite there. The Netbook is a clear winner if you're going to be doing much typing; the iPad is a clear winner if you're going to be doing more reading.
I wasn't trying to argue that. Indeed, I think it would be great if Firefox used a different process/thread for each page. I'm arguing *for* that.:)
My apologies; it sounded like what you were arguing was "processes are better than threads, because (1) the OS's scheduler is better than what you'd write and (2) the OS can schedule the tasks on multiple cores." Your parent was comparing threads vs processes (saying threads were better because processes are more heavyweight), then you open up with "In my experience, the process-per-page (be they tab, window, or whatever) yields much better performance", so I thought you were arguing for processes over threads. ("Heavyweight over lightweight processes" if you prefer.)
On Linux, at least, Firefox uses multiple OS threads, but the bulk of the work appears to be done in a single thread. If multiple pages are busy, you don't see other threads picking up the load; you just see that one thread doing more work. I presume the other threads are helper/utility things, such as network I/O or name lookup.
I believe there are multiple reasons for this. For starters, the OS already has a perfectly good scheduler, and it makes sense to use that to handle multi-tasking. Indeed, OS people prolly know more about how to design a scheduler than browser people. By exposing the this to the OS, it also means the OS can do whatever tricks it has to make I/O, memory allocation, etc., more efficient on a per-page basis,...
What makes you think that threads aren't exposed to the OS?
Okay, there are userland thread libraries, but they're not what people are talking about when they say that each tab runs in its own thread or something. 99.9% of the time now, "threads" are either OS threads or userland threads implemented in a library that provides a rather higher-level abstraction than just threads, such as Cilk or TBB.)
Of course, Firefox doesn't actually increase the number of OS threads when you open new tabs, so one of three things is true: 1. The number of threads is independent of the tabs you have open 2. FF is keeping a pool of threads (either itself or a library like I mentioned above) and doing userland scheduling among them 3. FF violates what I said above and actually is using userland threads in a pretty dumb way (unlikely)
Regardless of what Firefox is or isn't doing, "letting the OS know" is most definitely not an argument to not use threads.
However, after skimming over the decision I see no mention of the issue of this being an ex post facto law w.r.t. using things that were in the public domain, but suddenly weren't.
Technically it wouldn't be ex post facto either. The law forbids copying, selling those copies, etc.
You certainly couldn't be charged with any copies you made during the time it was in the PD, but you could be charged with any copying or distribution done after the work was removed from the public domain.
A better constitutional argument would be some sort of 5th amendment thing, but I'm not sure that's going through either.
That already justifies what I said in my previous post: the object piping already makes PS quite far from a ripoff of Bash. The rest of the stuff you say about the consistency of the utilities PS provides is really irrelevant to this point, no matter how true it is.
(For the record, the reasons I dislike PS involve: (1) subjectively very long startup times, (2) the fact that it's not installed by default and setup seems harder than it "should" be, and (3) the failure to fix several of the things I don't like about the native cmd.exe, at least without more investigation (e.g. the tab-completion behavior, behavior of the up and down arrow keys, and the continued use of the awful terminal that Windows provides). Add to that the ability to drop to Cygwin Bash or SSH to a real Linux box for a moment for things that are more complicated than 98% of what I do in the shell, and you don't have a particularly compelling use case for PS.)
Slashdot Mirror
Perhaps I wasn't clear:
1. Longer lens means more camera shake
2. More camera shake means you need a shorter shutter
3. Shorter shutter means you need to compensate somewhere
4. Compensating means either narrower DoF (if you go with larger aperture) or higher noise (if you go with higher ISO)
Clear now?
Are you going to cite the magical photo fairies next?
I don't think 65 ft is all that unreasonable, but understand that it will make a lot of photography rather harder. Longer lenses mean heavier lenses, which, as you say, means you'll probably need a shorter exposure, at least if hand-held. (Setting up a tripod can often take too long for non-posed photos.) But a shorter shutter means that you'll be compromising somewhere else: narrower depth of field or higher ISO. Narrow DOF can be nice for some artistic shots; less nice for most photojournalism. Sure, these things probably aren't so important if it's nice and sunny out, but what about if it's cloudy? Balancing all of these things can quickly become difficult.
But the real problem is that of perspective. Unless you carry around a 40' self-supporting tower with you, having to stay 65' out means that your angle is going to be MUCH lower. That does two things. First it will make it much easier for your view to be blocked. Instead of walking up to a line of grass and photographing over it, you have to photograph through it. Instead of getting closer and photographing from above the waves, you have to wait until they line up in such a way that nothing's in the way of your shot. It also means a lower angle on the ocean, which may well mean that it's harder to see the oil.
In short, putting a long lens on your camera isn't the same as walking up to something, for a number of reasons, and if you think it is, you should go back to photo school.
Way to mention the results aren't actually statistically significant:
(Emph. mine)
Who the crap modded that a troll?
My joke was illustrating a clearly absurd example where modern operating systems do enforce it, so that the reader might ask why it can't do the same for these security features as well.
As has been said many times in this thread, it can. As a user, you can tell Windows to always enforce DEP. Just expect that you may not be able to run all your software, which is why it's not configured that way by default.
MS didn't get where it is by breaking backwards compatibility with a ton of Windows programs, that's for sure.
It can easily be circumvented with a return-to-libc attack.
Hell, it's worse than that: read this 2005 Usenix security conference paper (PDF). It's been a while since I read it, so I can't remember exactly how they did it, but the gist the following. Pretty much all of these attacks require overwriting a return address or function pointer or something like that, so that control transfers to your injected code, to the function in libc that you want to execute (return-to-libc), etc. There are a variety of techniques to detect that sort of thing (especially return address clobbering) with relatively low overhead. The authors of that paper illustrate how you don't even have to do that: just overwriting program data suffices.
Now, that said, I don't not put on my seatbelt when I'm in a car simply because seatbelts don't prevent all deaths (to use an analogy of another poster). As long as people keep using unsafe languages like C, the goal is just going to be reducing the attack surface for even "dumb" attacks like buffer overflows. And DEP does that reasonably well.
Second whoever said 'flash can't do DEP' needs to stop injecting their ignorance into the conversation.
Actually, while I am all for bashing Flash at most opportunities, really the summary/article is right here.
DEP is enabled on a per-process basis. Flash doesn't create its own process, the browser does: therefore Flash has no say in whether it runs with DEP or not.
(In fact, another poster somewhere above says Flash is actually "DEP-clean", so if the browser starts with DEP enabled, Flash won't cause it to bomb.)
In my understanding, "application" means a piece of software with which users interact directly. "Program" means a piece of software in general, even kernels and libraries are programs.
This is a pretty dumb argument because it doesn't matter much, but just for anther perspective, I'm not as "loose" with what "program" means as you are. To me, a "program" is something that the OS can turn into a process -- this makes the program/process distinction but makes the terms very related. That definition excludes the kernel and libraries. (Though to add to the confusion, I might consider the actual code in a library as "program code".)
As for program vs application, that's much more hazy. Something like Word or Firefox is definitely an application; something like Grep probably isn't (though it's definitely a program). "Application" to me means something that 1. the user interacts with (no daemons), 2. is reasonably heavyweight (so no Grep), and 3. is actually doing something the user wants to do, as opposed to a more supporting task (so no window manager).
I'm not saying I'm right or my definitions are better than yours or anything like that, just giving another viewpoint.
Dell stood out because they formalized a real manufacturing process, setup good quality controls, made it brain dead simple to order, and *still* had prices that were just about the best you could get. They had a refined image with organized, glossy ads, which helped a lot.
Not to mention consistently placed in the top couple spots in customer satisfaction surveys.
I haven't payed attention in a decade, but I wonder where they are now...
I didn't post that to say "go police for arresting this kid in this case" (I think authorities are extremely quick to overreact in general), just to point out that dry ice bombs can easily actually do damage.
Hell, 2 OS cycles: moving off of the 9x kernel onto NT, and then Vista. Both made significant progress on this front.
This is such a stupid article I'm surprised it wasn't posted by kdawson.
The other poster is exactly right; I grew up in central PA.
I actually just got done writing a paper and my advisor kept marking "a couple " phrases in it. I actually made an emacs minor mode (based on hi-lock) that highlights a couple of idioms (and Latex mistakes) I need to avoid, and "a couple" followed by something other than "of" was one of them. :-)
You can do it harmlessly, but by point of contrast, a couple kids in my high school did that, and actually hurt a teacher who got hit by shrapnel.
While $50 isn't cheap, it's still a fair bit of money for something that is likely a bit of a longshot. From the description it sounds likely to NOT be other Wi-Fi, so a device that looks for Wi-Fi connections isn't the appropriate tool.
I find it amusing that you say "There is no point in encrypting your communication with [UNKNOWN]" and then go on to say "Uh, the more trust the better. It is not black and white."
But it's precisely because trust isn't black-and-white that there can be a point of encrypting your communication with UNKNOWN. If I trust that carrying out a MITM attack is harder than snooping on unencrypted traffic, then there is a point to encrypting without authentication.
Khan = Muslim
Or a genetically-engineered Indian.
News links off of slashdot, forums, imageboards, wikis, none of these need javascript.
News links off of slashdot don't, but with what I get when I'm not signed in, reading comments I think does. Some things in many forums need JavasSript -- spoiler tags for instance, or Fark's quote button. (Sure, you don't need to have that last feature, but it's so useful I'd question your sanity if you regularly participated in discussion there and didn't use it.) On Flickr (not really an imageboard, but still), JavaScript enables a far more usable uploader at least. Dpreview uses a dropdown menu for navigation; without the onselect event, the only way to go to a specific page is by changing the URL or hitting prev/next a bunch.
Just to drive this point home, it's less an hour and a half later, I haven't been browsing the internet, and I've already found a new site that I needed to enable JavaScript for.
A tenth? What Internet are you using?
My my estimation based on the scroll bar position after counting for a while, I've got about 250 websites listed with site-specific preferences; some of those will just have plugins enabled so I can look at PDFs, but most are to enable JavaScript.
They range from a couple dozen sites that I want to watch some Flash video on (enabling plugins but leaving JS off doesn't seem to work) to online stores (NewEgg and Best Buy both need JS for nearly essential features) to two of my banks (one of which doesn't actually need it I think, but it adds a few neat features; the other I think needs it) to some discussion-centric sites (even /. by default, but also things like Blogspot if you want to add comments) to the social networking sites to sites like this.
I can't say for certain what percentage of the sites I visit I have whitelisted, but rarely does a day go by when I don't discover some new site to add.
What's the problem with input? Are you hinting at the inconvenience of typing text on an iPad? This is trivially taken care of by providing an external keyboard with a dock to conveniently position the screen. Throw in an external display connector, and you're all set.
But how portable is such a setup really? As compared to, say, a Netbook? Could you use it in your lap?
I disagree that they are in the same space... it's close, but not quite there. The Netbook is a clear winner if you're going to be doing much typing; the iPad is a clear winner if you're going to be doing more reading.
I wasn't trying to argue that. Indeed, I think it would be great if Firefox used a different process/thread for each page. I'm arguing *for* that. :)
My apologies; it sounded like what you were arguing was "processes are better than threads, because (1) the OS's scheduler is better than what you'd write and (2) the OS can schedule the tasks on multiple cores." Your parent was comparing threads vs processes (saying threads were better because processes are more heavyweight), then you open up with "In my experience, the process-per-page (be they tab, window, or whatever) yields much better performance", so I thought you were arguing for processes over threads. ("Heavyweight over lightweight processes" if you prefer.)
On Linux, at least, Firefox uses multiple OS threads, but the bulk of the work appears to be done in a single thread. If multiple pages are busy, you don't see other threads picking up the load; you just see that one thread doing more work. I presume the other threads are helper/utility things, such as network I/O or name lookup.
Right; that was sort of my tacit accusation.
I believe there are multiple reasons for this. For starters, the OS already has a perfectly good scheduler, and it makes sense to use that to handle multi-tasking. Indeed, OS people prolly know more about how to design a scheduler than browser people. By exposing the this to the OS, it also means the OS can do whatever tricks it has to make I/O, memory allocation, etc., more efficient on a per-page basis,...
What makes you think that threads aren't exposed to the OS?
Okay, there are userland thread libraries, but they're not what people are talking about when they say that each tab runs in its own thread or something. 99.9% of the time now, "threads" are either OS threads or userland threads implemented in a library that provides a rather higher-level abstraction than just threads, such as Cilk or TBB.)
Of course, Firefox doesn't actually increase the number of OS threads when you open new tabs, so one of three things is true:
1. The number of threads is independent of the tabs you have open
2. FF is keeping a pool of threads (either itself or a library like I mentioned above) and doing userland scheduling among them
3. FF violates what I said above and actually is using userland threads in a pretty dumb way (unlikely)
Regardless of what Firefox is or isn't doing, "letting the OS know" is most definitely not an argument to not use threads.
However, after skimming over the decision I see no mention of the issue of this being an ex post facto law w.r.t. using things that were in the public domain, but suddenly weren't.
Technically it wouldn't be ex post facto either. The law forbids copying, selling those copies, etc.
You certainly couldn't be charged with any copies you made during the time it was in the PD, but you could be charged with any copying or distribution done after the work was removed from the public domain.
A better constitutional argument would be some sort of 5th amendment thing, but I'm not sure that's going through either.
You've just invalidated your own point.
I don't think you read the thread very carefully.
My statement as to both PS's strength and novelty is directed solely towards object piping. The presence of piping objects rather than a text text stream is pretty novel. Something like this is about as close as I've seen in any other environment. And I really like the idea. Do you want me to go into why? (That said, I suppose it's possible that if someone would go and write objbash and a corresponding set of utilities it would turn out that it's not all it's cracked up to be, but I have enough experience with programming in general, using REPLs, and using shells that I'm pretty confidant in my assessment of what a well-implemented object-based shell would do for you.)
That already justifies what I said in my previous post: the object piping already makes PS quite far from a ripoff of Bash. The rest of the stuff you say about the consistency of the utilities PS provides is really irrelevant to this point, no matter how true it is.
(For the record, the reasons I dislike PS involve: (1) subjectively very long startup times, (2) the fact that it's not installed by default and setup seems harder than it "should" be, and (3) the failure to fix several of the things I don't like about the native cmd.exe, at least without more investigation (e.g. the tab-completion behavior, behavior of the up and down arrow keys, and the continued use of the awful terminal that Windows provides). Add to that the ability to drop to Cygwin Bash or SSH to a real Linux box for a moment for things that are more complicated than 98% of what I do in the shell, and you don't have a particularly compelling use case for PS.)
They haven't been doing great (unlike, say, Apple), but at the same time it's not like they're particularly hurting.