Just to nitpick; as ADSLGuide.org.uk makes clear, UK DSL is 512k down, 256k up for the home service (theoretical 50:1 contention, although I've never seen it here on a DSL line in Durham). Business services are 512k, 1M or 2M down, 256k up, at a theoretical 20:1 contention. They did trial ADSL services with higher uplinks, but never released them.
Firstly, the "new" style sheet appeared for Opera *after* Opera became able to render the page correctly with the default stylesheet (as served up for MSIE). Secondly, even now, connecting as Opera gets a borked stylesheet. Connecting as MSIE gets a working sheet.
The question I want answered is *why* MSN started to serve an Opera specific version, *once* Opera was capable of rendering the MSIE version. Until that point, they were happy to serve Opera users the MSIE style sheet. Coincidence?
OTOH, every smartphone I've considered (and my next phone *will* be the Sony Ericsson P800) does work just like any other cellphone for standard voice calls (dial the number and press Yes to call, press Yes to answer a call, press No to hang up). It's only when you want to use the "gimmicks" that they become more complex.
And there are good uses for some of the technologies you mention. Text messaging is *extremely* useful for getting in touch with people who may possibly be in a meeting (you get your message across, and they can judge whether or not it's worth responding, or if they should wait until they escape). Surfing the Internet has at least two good uses; firstly, my network provider (Orange UK) offers a "Where's My Nearest" service (find cash machines, petrol stations etc). Secondly, Directory Enquiries costs more to call than it does to access via WAP.
Further, it is possible to get a better credit rating by fouling up in the right sort of way. Simply because I went and spoke to my bank manager when I'd completely mismanaged my finances, and got them to help me sort myself out, I have a better credit rating than someone who's always taken care to live within their income.
Fair? I Reasonable? I don't think so. Why should I be treated as a better credit risk, just because when I foul up I do the right thing? Why should people be penalised for never fouling up?
You've slightly missed my point; by the time the developers know of a bug, the black hats probably do too. Most of them won't be interested in anything beyond checking they can wreck a few machines; some will appreciate the flattery they get when they give the exploit to script kiddies.
Yes, there's a risk that a cracker who wouldn't have attacked me will get the exploit from Bugtraq and get me; there's also a risk that a cracker will obtain the exploit from a source that I have no access to. I'd say that the chances of them obtaining an exploit from a source I'm not aware of is about the same as them getting a bugtraq or similar notice before me.
Given this, I'd like to make my own judgement call on just what that risk is. Someone telling me that "there is a bug in ssh that will cause you a whole world of hurt" does not tell me what degree of risk I'm taking by not closing ssh. Someone telling me that someone can wipe my hard discs via ssh if they do the following allows me to judge the risk for myself. Maybe it's not applicable because I don't have the specific setup that exposes the risk; maybe the risk is very low, and only applies to me under special circumstances. Or maybe it's a big risk, and I should take countermeasures immediately.
The point is that unless I know enough about the bug to exploit it, I don't know whether the risk is one I'm prepared to accept.
Nope; firstly, I have enough knowledge to disable or firewall off the services that are being exploited (and this would include disabling scripting in IE if IE ran under Linux).
Secondly, I'd rather *know* what an exploit looks like, and thus be able to create a filter to prevent exploit packets incoming rather than just hoping that an exploit doesn't exist (because if it does, the black hats will have it, and the script kiddies will get hold of it).
Thirdly, I have enough knowledge to help join in the effort to fix the bug; I'm not the only person with that sort of knowledge. In the situation you describe, I can attempt to tackle bugs that affect me; I'm not dependant on someone else doing it for me. Even if I was dependant on other people, I'd still prefer them to have the extra visibility into the problem that an exploit provides. I've had to debug similar errors before, and while the debugging is the hardest part, the second hardest is creating a useful test case; in your situation, I have a test case already.
Slashdot Mirror
Just to nitpick; as ADSLGuide.org.uk makes clear, UK DSL is 512k down, 256k up for the home service (theoretical 50:1 contention, although I've never seen it here on a DSL line in Durham). Business services are 512k, 1M or 2M down, 256k up, at a theoretical 20:1 contention. They did trial ADSL services with higher uplinks, but never released them.
A scheme charging per spam e-mail received might or might not work, but this incident does not indicate whether or not it would.
The question I want answered is *why* MSN started to serve an Opera specific version, *once* Opera was capable of rendering the MSIE version. Until that point, they were happy to serve Opera users the MSIE style sheet. Coincidence?
And there are good uses for some of the technologies you mention. Text messaging is *extremely* useful for getting in touch with people who may possibly be in a meeting (you get your message across, and they can judge whether or not it's worth responding, or if they should wait until they escape). Surfing the Internet has at least two good uses; firstly, my network provider (Orange UK) offers a "Where's My Nearest" service (find cash machines, petrol stations etc). Secondly, Directory Enquiries costs more to call than it does to access via WAP.
Fair? I Reasonable? I don't think so. Why should I be treated as a better credit risk, just because when I foul up I do the right thing? Why should people be penalised for never fouling up?
Yes, there's a risk that a cracker who wouldn't have attacked me will get the exploit from Bugtraq and get me; there's also a risk that a cracker will obtain the exploit from a source that I have no access to. I'd say that the chances of them obtaining an exploit from a source I'm not aware of is about the same as them getting a bugtraq or similar notice before me.
Given this, I'd like to make my own judgement call on just what that risk is. Someone telling me that "there is a bug in ssh that will cause you a whole world of hurt" does not tell me what degree of risk I'm taking by not closing ssh. Someone telling me that someone can wipe my hard discs via ssh if they do the following allows me to judge the risk for myself. Maybe it's not applicable because I don't have the specific setup that exposes the risk; maybe the risk is very low, and only applies to me under special circumstances. Or maybe it's a big risk, and I should take countermeasures immediately.
The point is that unless I know enough about the bug to exploit it, I don't know whether the risk is one I'm prepared to accept.
Secondly, I'd rather *know* what an exploit looks like, and thus be able to create a filter to prevent exploit packets incoming rather than just hoping that an exploit doesn't exist (because if it does, the black hats will have it, and the script kiddies will get hold of it).
Thirdly, I have enough knowledge to help join in the effort to fix the bug; I'm not the only person with that sort of knowledge. In the situation you describe, I can attempt to tackle bugs that affect me; I'm not dependant on someone else doing it for me. Even if I was dependant on other people, I'd still prefer them to have the extra visibility into the problem that an exploit provides. I've had to debug similar errors before, and while the debugging is the hardest part, the second hardest is creating a useful test case; in your situation, I have a test case already.
It's still based on the same instruction set, it's just a newer chip. Same sort of change as Intel 486 to Intel Pentium.