No, it doesn't matter when it comes to logging your keystrokes and obtaining your credit card numbers/banking info/passwords.
Actually, on Mac OS X, it does matter.
If the app is written properly and uses EnableSecureEventInput while the user is entering passwords (as recommended in TN2150), then event taps won't get you passwords.
Only processes running as root can seize keyboards as of 10.5, preventing password capture down at the device access level as well.
Only processes running as root can load kernel extensions, preventing it at the driver level.
Thus, to my knowledge, unless you exploit a bug in the OS, it should not be possible to sniff passwords in Mac OS X unless an app is running as root.
That's not to say that it can't steal passwords in other ways—spoofing password dialogs, stealing your Safari cookie files, reading your Safari bookmarks and pretending to be Safari while it displays your bank's website, etc.—but it should not be able to capture passwords that you enter in other applications. Thus, root matters. A lot.
It is typically one of the first to fall in White Hat conventions, which of course leads to quick patches to close any vulnerabilities.
To be fair, at most of those contests, more people are trying to win the Mac than the Windows box, thus making the amount of time to breach a largely uninteresting metric when it comes to determining how secure the OS is.
A more interesting metric is how long known security bugs go unpatched. Unfortunately, accurately obtaining such metrics without a colossal leak would be impossible.
Also, there's the problem that probably at least 99% of security bugs aren't reported as security bugs, and thus tend to get buried in bug tracking systems as "app crashes in obscure use case" for years on end. My rule when writing code is simple: if it crashes, always assume it's a security bug. Not everybody is that strict, though, unfortunately, hence the reason anybody still ships Flash preinstalled....
No, not really. If this were an exam that you take on the way out of med school, then yes, it would be more abhorrent. On the way in, all it does is mean that some people who shouldn't have been admitted will waste a whole lot of money unsuccessfully trying to pass classes that they weren't really ready for.
I'd expect that anybody who couldn't take the MCAT and do well on his/her own would wash out of med school anyway. It's not like you can keep up that sort of charade all the way through med school. When the prof asks you questions in class and you show a complete inability to think on your feet, when you can't pull off the most basic tasks during lab sections, or when you prove completely inept during your residency, they're gonna know that you're not cut out for a career as a doctor.
Basically, cheating works until you get caught. If you keep cheating, you will eventually get caught. The severity of the punishment tends to be directly proportional to how long you went without getting caught. Therefore, cheating is something that only a moron would do for very long. Ignoring the ethical question for a moment, this means that it can only be useful as a way of getting past some seemingly impossible hurdle like getting a near-perfect score on the MCAT so you can get into a top-tier medical school instead of having to settle for a lesser school.
So basically, it's not very likely that this would have any real negative impact on the quality of medical care (beyond the question of whether you'd want somebody with such poor ethical judgment taking care of you). And ironically, it might actually improve medical care if the lesser students went to the better schools and vice versa. In short, the only people who are really harmed by this are the other people taking the MCAT, who are competing against these alleged cheaters for spots in specific medical schools. This is not to say that the behavior is excusable, just that it is no more abhorrent than cheating on a GRE, an SAT, an ACT, or any other school entrance exam.
And by a metaphorical interpretation of the Bible, that's probably not far from the truth. You would expect that given billions of billions of subatomic particles combining in a great cosmic soup, the first things that would form are light elements, and some of the first compounds would be compounds of light elements—water, for example—long before the sorts of heavy elements and compounds that make up rocks would form.
I usually find Fry's and RS's selection to be complementary. Fry's has cheaper parts, but there are a fair number of things that RS carries, but Fry's doesn't. For example, unless they've added it recently, Fry's doesn't carry the ubiquitous 555 timer IC. They also don't stock certain small values of film caps that I use regularly. Radio Shack has both.
Radio Shack doesn't sell tips for their Weller soldering gun through stores, either. They also don't sell it on their online store, but there's a part number in their system for it, which means they can order it for you. I guess, the number of people who buy new tips is small enough that they don't bother to stock them. I mean, how often do you replace tips? By the time you need your first replacement, the iron is usually a decade old....
I see people have trouble with just async stuff (e.g. AJAX) and have a hard time wrapping their mind around the fact that even though the callback function is in-sequence with the rest of the code, it's not actually called in that sequence - hence the 'callback'.
In my experience, the reason people have so much trouble with async stuff is that every single JavaScript API I've seen that does things asynchronously is rather fundamentally designed *wrong*. They don't provide any clean mechanism for passing data structures with variables from the calling function into the callback short of constructing a helper function on the fly. Since most people have a hard time wrapping their head around the concept of creating anonymous functions, many programmers end up using global variables. This works until things happen out of order or they need to use that code in parallel. Then, things break miserably, and the entire mechanism falls flat.
Also, JavaScript overuses callbacks. If you can't guarantee that other things won't happen in the DOM tree before the callback fires anyway, it would be a much saner design to simply declare that "this synchronous call may block, and while this call is blocked, other activity may occur". The only thing callbacks do in JavaScript is force you to do a crapton of extra work to pass local variables into the callback. This callback-heavy design causes a lot of extra work for developers, while providing exactly zero benefit. It's not like JavaScript is raw code running in a native thread or anything—the main program loop isn't JavaScript code; it's part of the interpreter—so it's almost exactly as easy for the interpreter to save off the function state and restore it transparently as it is for that interpreter to handle a return statement and trigger a callback at a particular point.
Compared with JavaScript, parallel programming using sane languages and sane APIs is trivial. Contrast the JavaScript custom function kludge with the much cleaner block syntax used by Apple, or even plain old C callbacks with refCon/userData parameters, and it's easy to see why people hate writing asynchronous code in JavaScript. It's not that writing asynchronous code is inherently hard, but rather that writing asynchronous code in a language that goes out of its way to make it hard, and using an API set that similarly goes out of its way to make it hard is inherently hard.
Of course, this is an article on smartphones, which makes your post kind of amusing. PagePlus Cellular has no real data plans (their best plan only provides 100 MB of data per month; you can go through that in about 45 minutes of YouTube viewing if you don't notice that your Wi-Fi link went down). Then what? They don't offer the ability to buy extra data traffic, so as far as I can tell, your only choice is to buy a second month for another $30, chock full of minutes that you're never going to use.
There are no good cellular services. There are only bad cellular services and worse cellular services.
The article made it sound like you have one instance of a JavaScript server that runs as part of your web server (Apache, presumably) and all JavaScript requests get funneled into a handler, all within a single thread. Apparently, that's not the case. Thus further emphasizing the point that the article doesn't describe things too well.:-)
While we're at it, the JavaScript engines are all single-threaded per server? So you get no benefit from having multiple cores or multiple CPUs in your server? What a colossal train wreck of a design.
You have a poor conception of what the most common use case is. Generally, users have one document open on the left... and Facebook open on the right. Just saying.
But you can ignore a reflection. After a minute or two, your brain cancels it out. It's impossible to ignore "my text looks like medium grey on light grey".
Even for many programming tasks, I find width to be more important. Most of the time, I'm tracing execution back and forth between three or four different classes in different files. Being able to see more than twenty or thirty lines of code is rarely as important as being able to glance between vi windows.
Now sure, if I could, I'd have about eight portrait mode displays lined up right next to each other, but that doesn't mean that height is more important, but rather that I wouldn't mind both dimensions being larger.
90% of the time I am surfing the 'net, and therefore height is far more important to me. More height means less scrolling. You don't know what you're talking about.
...a task for which a portrait mode display (such as an iPad) would be more appropriate.
Well, sure, but we also benefit from vertical view splits, etc. that most people would never even be able to figure out how to use. Programmers are the one-half-of-one-percent case as computer users go.:-)
I realize that shiny sells, but I still don't understand why I can't buy a 4:3 laptop these days. Everyone I talk to says he'd prefer one to the current wide-screen offering. Do people really only use computers for watching movies?
In practice, most users find that width is more important than height. You have two documents. Do you place one beside the other, or one above the other? Most people put them beside one another. The only thing extra height buys you is seeing more of a single document at once, and beyond a certain point (usually a couple of paragraphs), this turns out to not be a significant benefit for most people.
The people who benefit significantly from taller screens are mostly people reading books—a task for which a portrait mode display (such as an iPad) would be more appropriate.
In other words, it's another case where what users say they want isn't necessarily what would actually serve their needs best.
The stupid thing with glossy screens is that they're completely unusable in the sun.
Actually, I would say the opposite is true. Matte screens are completely unusable in sunlight because they wash out to the point that you can't see anything. With glossy screens, they are usable outdoors, so long as the sun is not directly behind you. You can adjust the angle to get the hot spot to disappear. With a matte screen, you get a washed out view at any angle.
I use my glossy-screened iPhone outside all the time. By contrast, my TomTom's matte screen from about the same year is almost completely unreadable at certain times of day.
How many hard drives do you typically connect to your computer externally at the same time?
Sure, with USB you can plug half a dozen drives in, but to get the same performance as the previous eSATA generation, you'd still need one bus per device, same as with eSATA, so about the only advantage there is that you don't have to unplug cables every so often. Either way, if you have more than two external storage devices attached at the same time, you're at least a couple of standard deviations above the norm in terms of your storage needs.:-)
SATA 3 has only been out for what, two years? And besides, that's assuming an otherwise idle CPU. Load up the CPU doing real work, and USB 3 starts to take a much bigger toll on performance.
Slashdot Mirror
I'm not rationalizing it. I'm just saying that it is not automatically worse than any other type of cheating merely because medicine is involved.
Actually, on Mac OS X, it does matter.
Thus, to my knowledge, unless you exploit a bug in the OS, it should not be possible to sniff passwords in Mac OS X unless an app is running as root.
That's not to say that it can't steal passwords in other ways—spoofing password dialogs, stealing your Safari cookie files, reading your Safari bookmarks and pretending to be Safari while it displays your bank's website, etc.—but it should not be able to capture passwords that you enter in other applications. Thus, root matters. A lot.
To be fair, at most of those contests, more people are trying to win the Mac than the Windows box, thus making the amount of time to breach a largely uninteresting metric when it comes to determining how secure the OS is.
A more interesting metric is how long known security bugs go unpatched. Unfortunately, accurately obtaining such metrics without a colossal leak would be impossible.
Also, there's the problem that probably at least 99% of security bugs aren't reported as security bugs, and thus tend to get buried in bug tracking systems as "app crashes in obscure use case" for years on end. My rule when writing code is simple: if it crashes, always assume it's a security bug. Not everybody is that strict, though, unfortunately, hence the reason anybody still ships Flash preinstalled....
No, not really. If this were an exam that you take on the way out of med school, then yes, it would be more abhorrent. On the way in, all it does is mean that some people who shouldn't have been admitted will waste a whole lot of money unsuccessfully trying to pass classes that they weren't really ready for.
I'd expect that anybody who couldn't take the MCAT and do well on his/her own would wash out of med school anyway. It's not like you can keep up that sort of charade all the way through med school. When the prof asks you questions in class and you show a complete inability to think on your feet, when you can't pull off the most basic tasks during lab sections, or when you prove completely inept during your residency, they're gonna know that you're not cut out for a career as a doctor.
Basically, cheating works until you get caught. If you keep cheating, you will eventually get caught. The severity of the punishment tends to be directly proportional to how long you went without getting caught. Therefore, cheating is something that only a moron would do for very long. Ignoring the ethical question for a moment, this means that it can only be useful as a way of getting past some seemingly impossible hurdle like getting a near-perfect score on the MCAT so you can get into a top-tier medical school instead of having to settle for a lesser school.
So basically, it's not very likely that this would have any real negative impact on the quality of medical care (beyond the question of whether you'd want somebody with such poor ethical judgment taking care of you). And ironically, it might actually improve medical care if the lesser students went to the better schools and vice versa. In short, the only people who are really harmed by this are the other people taking the MCAT, who are competing against these alleged cheaters for spots in specific medical schools. This is not to say that the behavior is excusable, just that it is no more abhorrent than cheating on a GRE, an SAT, an ACT, or any other school entrance exam.
Well, there might be one.
And by a metaphorical interpretation of the Bible, that's probably not far from the truth. You would expect that given billions of billions of subatomic particles combining in a great cosmic soup, the first things that would form are light elements, and some of the first compounds would be compounds of light elements—water, for example—long before the sorts of heavy elements and compounds that make up rocks would form.
Goatse link, not that this is a surprise.
I usually find Fry's and RS's selection to be complementary. Fry's has cheaper parts, but there are a fair number of things that RS carries, but Fry's doesn't. For example, unless they've added it recently, Fry's doesn't carry the ubiquitous 555 timer IC. They also don't stock certain small values of film caps that I use regularly. Radio Shack has both.
Radio Shack doesn't sell tips for their Weller soldering gun through stores, either. They also don't sell it on their online store, but there's a part number in their system for it, which means they can order it for you. I guess, the number of people who buy new tips is small enough that they don't bother to stock them. I mean, how often do you replace tips? By the time you need your first replacement, the iron is usually a decade old....
In my experience, the reason people have so much trouble with async stuff is that every single JavaScript API I've seen that does things asynchronously is rather fundamentally designed *wrong*. They don't provide any clean mechanism for passing data structures with variables from the calling function into the callback short of constructing a helper function on the fly. Since most people have a hard time wrapping their head around the concept of creating anonymous functions, many programmers end up using global variables. This works until things happen out of order or they need to use that code in parallel. Then, things break miserably, and the entire mechanism falls flat.
Also, JavaScript overuses callbacks. If you can't guarantee that other things won't happen in the DOM tree before the callback fires anyway, it would be a much saner design to simply declare that "this synchronous call may block, and while this call is blocked, other activity may occur". The only thing callbacks do in JavaScript is force you to do a crapton of extra work to pass local variables into the callback. This callback-heavy design causes a lot of extra work for developers, while providing exactly zero benefit. It's not like JavaScript is raw code running in a native thread or anything—the main program loop isn't JavaScript code; it's part of the interpreter—so it's almost exactly as easy for the interpreter to save off the function state and restore it transparently as it is for that interpreter to handle a return statement and trigger a callback at a particular point.
Compared with JavaScript, parallel programming using sane languages and sane APIs is trivial. Contrast the JavaScript custom function kludge with the much cleaner block syntax used by Apple, or even plain old C callbacks with refCon/userData parameters, and it's easy to see why people hate writing asynchronous code in JavaScript. It's not that writing asynchronous code is inherently hard, but rather that writing asynchronous code in a language that goes out of its way to make it hard, and using an API set that similarly goes out of its way to make it hard is inherently hard.
Of course, this is an article on smartphones, which makes your post kind of amusing. PagePlus Cellular has no real data plans (their best plan only provides 100 MB of data per month; you can go through that in about 45 minutes of YouTube viewing if you don't notice that your Wi-Fi link went down). Then what? They don't offer the ability to buy extra data traffic, so as far as I can tell, your only choice is to buy a second month for another $30, chock full of minutes that you're never going to use.
There are no good cellular services. There are only bad cellular services and worse cellular services.
The article made it sound like you have one instance of a JavaScript server that runs as part of your web server (Apache, presumably) and all JavaScript requests get funneled into a handler, all within a single thread. Apparently, that's not the case. Thus further emphasizing the point that the article doesn't describe things too well. :-)
While we're at it, the JavaScript engines are all single-threaded per server? So you get no benefit from having multiple cores or multiple CPUs in your server? What a colossal train wreck of a design.
You have a poor conception of what the most common use case is. Generally, users have one document open on the left... and Facebook open on the right. Just saying.
But you can ignore a reflection. After a minute or two, your brain cancels it out. It's impossible to ignore "my text looks like medium grey on light grey".
Even for many programming tasks, I find width to be more important. Most of the time, I'm tracing execution back and forth between three or four different classes in different files. Being able to see more than twenty or thirty lines of code is rarely as important as being able to glance between vi windows.
Now sure, if I could, I'd have about eight portrait mode displays lined up right next to each other, but that doesn't mean that height is more important, but rather that I wouldn't mind both dimensions being larger.
...a task for which a portrait mode display (such as an iPad) would be more appropriate.
Well, sure, but we also benefit from vertical view splits, etc. that most people would never even be able to figure out how to use. Programmers are the one-half-of-one-percent case as computer users go. :-)
In practice, most users find that width is more important than height. You have two documents. Do you place one beside the other, or one above the other? Most people put them beside one another. The only thing extra height buys you is seeing more of a single document at once, and beyond a certain point (usually a couple of paragraphs), this turns out to not be a significant benefit for most people.
The people who benefit significantly from taller screens are mostly people reading books—a task for which a portrait mode display (such as an iPad) would be more appropriate.
In other words, it's another case where what users say they want isn't necessarily what would actually serve their needs best.
Actually, I would say the opposite is true. Matte screens are completely unusable in sunlight because they wash out to the point that you can't see anything. With glossy screens, they are usable outdoors, so long as the sun is not directly behind you. You can adjust the angle to get the hot spot to disappear. With a matte screen, you get a washed out view at any angle.
I use my glossy-screened iPhone outside all the time. By contrast, my TomTom's matte screen from about the same year is almost completely unreadable at certain times of day.
How many hard drives do you typically connect to your computer externally at the same time?
Sure, with USB you can plug half a dozen drives in, but to get the same performance as the previous eSATA generation, you'd still need one bus per device, same as with eSATA, so about the only advantage there is that you don't have to unplug cables every so often. Either way, if you have more than two external storage devices attached at the same time, you're at least a couple of standard deviations above the norm in terms of your storage needs. :-)
Actually, yes, eSATA does, at least in modern versions.
And every eSATA drive has a USB connector. It's not like a hard drive has to choose just one connector.
http://www.tuaw.com/2011/04/14/intel-announces-usb-3-0-in-ivy-bridge-and-will-support-thunder/
SATA 3 has only been out for what, two years? And besides, that's assuming an otherwise idle CPU. Load up the CPU doing real work, and USB 3 starts to take a much bigger toll on performance.