Suicide is only attempted by those who are mentally ill.
No, people who come up with simplistic explanations for behaviours they don't understand are mentally ill.
People commit suicide for a variety of reasons. Most often, that life simply isn't appealing any more. The fact we don't like it when people do it doesn't make it an illogical decision.
Mod up +5 Insightful. For an example of this actually happening, there's Atheos, which was forked as Syllable when Atheos's developer disappeared from the scene.
In many ways this is one of the major intents behind the GPL: The GPL means you never have to put your faith in someone else when you use someone else's software. You are not limited by them. You are not giving them your testicles and a large hammer whenever you trust your data to something they wrote. Normally it's phrased in the conspiracy-driven language I just used, but it applies equally to situations where the reason for that lack of support could be entirely honest and unforseen, like Pat's situation today.
And on that note, may I wish Pat the best of luck. Whatever I move on to, Slackware will always have a soft spot for me, both as the first distro I used, and as the one that worked closest to the way I want such a distro to work. Slackware is a work of art.
You're not talking about technical measures, you're talking about psychological tricks. This is always going to be outside of the scope of this arena
You can almost certainly be traced. Server certificates need a hell of a lot more verified information than domain names. I registered a domain on my company's behalf and then proceeded to get the certificate. The amount of paper work we needed - articles of incorporation, tax records, etc - was far more than it's credible to expect from someone trying to get the password for one person's online banking account.
In short, if you're going to go this far, you might as well go down a different route that'll net more victims.
In a CRT monitor, an individual pixel is made up as a triangle with RGB on each corner.
Kinda. The problem actually isn't this (as others have pointed out, the precise pattern varies by CRT and some do use strips), but that computer pixels and CRT pixels are not one-for-one matches. CRTs tend to be "as many dots as the manufacturer could fit", and the red beam strikes red dots, blue blue, green green, etc, and all the red dots that the red electron beam is passing are illuminated during the time the red pixel is being transmitted.
As a result, this kind of anti-aliasing just isn't possible with a CRT. You can't really know, programatically, when each colour dots are going to be illuminated.
By comparison, LCDs have a 1:1 pixel colour component to screen pixel colour element mapping (assuming you're running it in full resolution of course, but if you have a 640x480 view stretched to fit a 1024x768 LCD screen then it's going to look pretty ugly regardless...), hence this trick works.
You wouldn't argue, surely, that in your money example, my giving you $10 means you have $10 you didn't have previously? Specifically, that nothing has been taken away, and you have something you previously didn't?
There's a difference between you being given unrestricted freedom to do whatever the hell you like, and you getting something you didn't have before. As we've all said before, the GPL gives you rights. You didn't have those rights before you agreed to the GPL. You may be able to find licenses that give you more rights, but that's irrelevent.
An EULA takes rights away. You started with fair use rights. If you agreed to an EULA, you agreed to waive those rights.
If you want to continue to argue this, please, show us a right the GPL takes away - and include the legal cite that says you had the right to it in the first place. Not "a license that gives you an additional right for a specific software product", a simple legal cite that says "By default, you have the right to X a copyrighted work, without agreeing to anything", and a place in the GPL where it says "You can't do X".
Sure, it won't be from the bank, and it may be difficult to come up with one that's signed by a trusted CA,
Indeed. A trusted CA will not sign a www.bankofslashdot.org certificate. Thus, at the very least, if the user goes to https://www.bankofslashdot.org or has that in their URL bar, their browser will reject, outright, the website, or present a warning - and not the ordinary warnings about "You are about to enter a secure website", but a non-disablable(sp) requester giving details of the certificate, that should at least make the user smell a rat, especially if they regularly visit the site and have never come across the error before.
There is no real way to defeat HTTPS itself. You can try other types of hack to get the information, including the most popular user psychology type hacks, but on a technical level, HTTPS is (to the best of anyone's knowledge) secure. It does what it does.
Internet Explorer (one of the most popular browsers) treats the option to "warn when going to a secure site" as the same as "warn when leaving a secure site".
That's not a problem. The warning that comes up for a bogus certificate or unsigned certificate doesn't appear in the same way. You can't disable it either.
Worse: could a hijacker/phisher create a non-secure page and use javascript to overlay the "secure lock" logo on the relevant parts of the browser window? And erm, draw the necessary "windows/dialogs" to help the user check the certs?
That would be relatively difficult without risking giving the game away. A different in appearance between the emulated browser and the real one (look at recent different versions of IE) or a slight change in functionality would likely give the game away. Sure, it may fool a number of people, but it would also be a dead giveaway to others, who'd be extremely likely to investigate.
Could the javascript stuff also pop up a dialog saying "You are about to view pages over a secure connection."? in response to the click? Many pop up blockers don't block popups directly triggered by the user.
Yes, that's possible. Again though there are a lot of risks involved.
In any case, my point was that the type of interception being suggested isn't practical. You can't break, in any of the ways described, HTTPS. You can install spyware, you can emulate a browser, you can do lots of things to get around the system, but you can't actually create a secure website that purports to be another in a generic, not exploting a specific browser's bug, way. That part is pretty solid. The types of DNS spoofing mentioned by the GGP aren't holes that the designers of HTTPS never thought of.
Your computer asks the Evil Access Point (EAP) to validate the cert, the attacker transmits that request directly to the bankofslashdot.com. A certified session is created.
And how is the attacker then going to decrypt the data send from the browser using the public key passed on from bankofslashdot.com?
Remember: bankofslashdot.com will not send private keys, neither for the certificate nor for the session. Only public keys will be sent. The certificate will be signed by an authority. The session encryption key with the certificate.
You can't intercept the communications, suddenly switching the source of data. If you could, you wouldn't need to go to such extremes anyway because you could decode everything sent anyway, without the need for a fake server.
No, it doesn't restrict any rights. Remember: you don't have the right to distribute the copyrighted code without source to begin with.
You can't take away a right you never had.
Understand that, and you understand why the GPL is not an EULA, and an EULA is an EULA. You start with the right to make backups for your own personal use, benchmark, reverse engineer, etc. These are all fair use. An EULA removes those rights, usually without granting any new ones.
Can I suggest you reread the explanation I posted? I'm really not sure what you're trying to say except to say that what you're saying doesn't make any sense.
You can't "fool" a certificate. The entire system is designed to check that the site claiming to be "www.bankofslashdot.org" really is "www.bankofslashdot.org". This is done not by checking IP addresses, but by ensuring that the site you're connecting to (a) has a signed certificate and (b) knows the private key part of that certificate.
If an attacker merely redirects browsers to a different web site, they'd still need the private part of that certificate, which is something they will not have. Why is that important? Because without the private part of the certificate, the spoof site cannot sign anything which means the browser will realise the site is fake immediately.
If an attacker tries to create a bogus certificate, for which they have the private part, they'll have problems getting it signed by any of the authorities whose keys are stored in every modern browser. (Want a list? Get Firefox [I don't have IE here so can't give the instructions for IE], check Preferences, Advanced, Certificates, Manage Certificates, Authorities.)
Unless the certificate is signed by an authority known to the browser, the browser will issue a warning, and while the average user might click through for unsigned certificates for "pr0n.net" or "fredsdiscountshop.com", they're sure as damn it not going to for their online banking. Indeed, in the latter case, the browser itself may actively prevent them from connecting if they've been to the site before and it had a legitimate, signed, certificate at that point.
There's no fooling the certificate. The certificate DOES NOT USE DNS. It associates a hostname with the certificate, but the entire point is to make sure that the machine that ultimately is connected to is the real thing, and the real thing could have any IP address.
You're saying, essentially, that the certificate system would be fooled by the very thing it was designed to prevent. It isn't. One of the primary reasons of designing it this way was to prevent this kind of attack. Otherwise, why store all the certs in a browser? It'd involve a hell of a lot less administration if we could just download the certificates automatically as we need them.
WEP is somewhat hackable, which is why I joked about the average geek using WEP and being 2% more secure...
There are, obviously, alternatives. I think the best would be using VPNs if only the average WAP would include VPN servers supporting the sixty or so "standard" VPN systems so you didn't need additional hardware for that kind of thing.
No, read the explanation again. The MitM can pass on the certificate but they can't sign the session key with that certificate's private key 'cos they don't have it.
-- the owner grants me permission to use the product if I agree to abide by the terms of the license.
That's not the case. You have the right to use the product anyway.
The GPL gives you additional rights not offered by default in copyright law. It doesn't require you do anything, it merely says "If you do such and such, in this kind of way, you're ok".
All of which is getting off-topic. The GPL is not an EULA, at least not usually (there are a lot of braindead installers out there I've noticed for OS X that force users to "Agree" to the GPL before installation, interestingly I wouldn't be surprised if non-copyright holders distributing such packages are actually violating the GPL by distributing it in such packages...
The GPL only grants rights. EULAs restrict them. The GPL says "You didn't have the right to do this before, you can now do this"; EULAs say "We don't care what copyright law says you can do, we're tearing up those rights and giving you an entirely new set."
No, that's not the point at all. The point is that it's very easy to set up a WAP that looks like someone else's WAP, so they log into it without realizing they're logging into someone else's network.
Of course, geeks are more likely to implement WEP et al, thus making it 2% less likely you'll be hacked in this way.
The lesson isn't "Don't take candy from strangers", it's "Check that your mother really is your mother before accepting candy from here: always ask for ID. She may be someone who's taken cosmetic surgery to look like your mother."
Except that this particular situation is a little less improbable.
No it isn't. DNS allows you to redirect the browser to look at a different IP address, but it doesn't give you access to a key you can use to tell a browser that "you really are connecting to "www.bankofslashdot.org" and Entrust/Verisign/etc have signed my key to say so."
Keys and certificates have nothing to do with DNS, they're actually there to confirm that you really are connecting to a specific machine, not just a machine with the right IP address.
Regular HTTPS (the usual SSL) includes a system of signed keys as part of the passing on of session keys that apply to specific host names. The signatures for those keys are signed by a small number of authorities whose credentials are usually built into the browser you're using - IE, Firefox/Mozilla, Opera, et al, come with these authority keys pre-loaded.
I don't know the exact technical details but I believe the process goes something like this:
Client: I want to make an HTTPS connection to your server www.bankofslashdot.org. Get the ball rolling by sending me your public key.
Server: Here it is. [String of several hundred binary digits follow]
Client: (Examines key) Ok, it's signed by Verisign, and it applies to www.bankofslashdot.org, the site I'm trying to connect to. Sounds good to me. Can you give me a session key I can use to encrypt information I send you?
Server: Here's the session key you're going to use, signed by my private key, which you can verify using the public key I just gave you
Client: (Encrypted) looks good, here's the session key you can use to send me information.
....
(In general RSA encryption is used. RSA is dual purpose, it can be used to sign information and to encrypt it. RSA keys have a public element and a private element. The public element can be used to encrypt information and verify signatures, but cannot be used to derive the private key. How does it work? Products of two very big prime numbers, don't ask me more than that 'cos I seriously don't know.)
A "man in the middle" would have a little bit of difficulty, as there's no way they could sign the session key they send to the client because that session key can only be signed if you have access to the private key, which they don't have.
If the key is invalid, or there isn't one signed by an authority to begin with (they're not compulsory), then browsers usually warn users.
The best I can think of is that you try to redirect a user to the wrong site. For example, the "Log in" button on http://www.bankofslashdot.org could redirect to https://www.blankofslashdot.org, though doing so would potentially expose the attacker as you have to prove you're real and you're the owner of the domain to most authorities to get a certificate for your key.
Anyone spotting obvious errors or wanting to fill in gaps in my explanation is most welcome to do so.
Given most DVDs are region encoded, regardless of whether they're for movies that came out in the cinema six months ago, or for movies that were released before video taping was ever invented, I think it's safe to say that region encoding doesn't really have a lot to do with cinema release dates.
If the radar says you have to stop, you have to stop. Regardless of who's behind you and what kind of utter idiot they are, you really have two choices - crash into what's in front, or put some trust in the driver behind you. There's only one logical answer to that.
This, incidentally, is also how it's recognized legally. Under most circumstances, in most of the juristictions I'm aware of (where all drivers are equal that is, there are some wierd racially-based driving rules in some countries too, but for the sake of argument, assume all other factors are equal) if someone brakes in front of you, even if it's just because they're an asshole, and you crash into them, you're the one at fault.
I suspect if we were to outlaw rear view mirrors tonight, whatever other types of accident may rise, the number of tailgaters would plummet and the number of accidents related to tailgating would do likewise. It's a shame banning rear view mirrors would probably cause more problems that it solves.
I didn't think user programs actually ran in usermode on Amigas.
Yes, they did. Only Exec (and the odd device driver's interrupt handler portion) ran in supervisor mode.
Despite every web page claiming it's impossible to recover from page fault on 68000 - it's not strictly true... as long as you run with the trace mode set.
You can store next instruction address and sr in the trace interrupt - then use this when an address/bus error occurs.
Of course, your performance would drop by 500% or so.
This is true but strictly semantics. It's obviously false that the 68000 cannot implement virtual memory in the same sense because you can always emulate a virtual machine. But in practice, for realistic applications, it's not really useful.
On the latter point, I always though it'd be interesting to write an OS that implemented signed executables, with a "valid" compiler being the thing that delivered the signatures. Then you'd implement all the VM handling in the compiler. Each program would be a little slower, but you'd have a rock solid no-app-can-crash-another-app type environment without needing hardware help.
Can't remember what SR is. If this is allowable and works the way you're suggesting, then this is a bug in the 68000. From memory though, the general design of the 68000 prevented programs running in User Mode from screwing with hardware interrupts.
There were, of course, bugs in the 68000, but the only two I remember were that it was possible for a user mode program to find out it was a user mode program, and that interrupts occured after an instruction was executed (which meant MMUs were impossible until the 68010, as you couldn't cleanly recover from a page fault with the original.)
No, it had pre-emptive multitasking. Many programs could crash without taking the system down. Every fiftieth or sixtieth of a second, a forced context switch occured. That's pre-emptive.
Because it lacked memory protection, a program that crashed (or merely had a bug) had the potential to take down the system, but that's another matter. Essentially it depended on the crash.
In a cooperative multitasking environment, the program:
hello: bra hello
will bring down the computer. On the Amiga, such a program caused no damage whatsoever except slowing down the machine.
In an environment without proper memory protection, the program:
hello: jsr hello
will probably crash the computer (though it might not if, say, the stack is located just above the program itself, so causing the program to be the first thing wiped by the crash.)
It's the lack of memory protection that's the problem with the Amiga.
That's good, although obviously there's also the links in the headers (like your http://ostermiller.org one) I suspect they're less suseptable to abuse because you can't link keywords to them by changing the text (the text is always the URL)
...and also make sure it only applies to the comment..sigs and other user-created all-comment links should have NOFOLLOW in every link by default regardless of the moderation of the message. Otherwise it just helps the sell-your-soul-for-a-chance-at-a-free-iPod spammers.
Wouldn't you say "actually, I'm not discriminating at all, it's just that men are generally more suited to this type of work"?
Yes, that's exactly what I'd say.
But you'd agree with me, surely, that there's a difference between a construction company that employs by skill level and has no problem employing women who meet that criteria, and one that doesn't interview women without a note from a lawyer.
It's worth noting that in general discrimination lawsuits, those that aren't frivilous, rarely rely on employment mix figures. Indeed, where such mixes are mentioned, it's usually by the defense ("We can't possibly discriminate against women, why two of our senior managers are women!")
It's always a little eye opening reading the complaints and what provokes these kinds of lawsuits.
Slashdot Mirror
People commit suicide for a variety of reasons. Most often, that life simply isn't appealing any more. The fact we don't like it when people do it doesn't make it an illogical decision.
In many ways this is one of the major intents behind the GPL: The GPL means you never have to put your faith in someone else when you use someone else's software. You are not limited by them. You are not giving them your testicles and a large hammer whenever you trust your data to something they wrote. Normally it's phrased in the conspiracy-driven language I just used, but it applies equally to situations where the reason for that lack of support could be entirely honest and unforseen, like Pat's situation today.
And on that note, may I wish Pat the best of luck. Whatever I move on to, Slackware will always have a soft spot for me, both as the first distro I used, and as the one that worked closest to the way I want such a distro to work. Slackware is a work of art.
- You're not talking about technical measures, you're talking about psychological tricks. This is always going to be outside of the scope of this arena
- You can almost certainly be traced. Server certificates need a hell of a lot more verified information than domain names. I registered a domain on my company's behalf and then proceeded to get the certificate. The amount of paper work we needed - articles of incorporation, tax records, etc - was far more than it's credible to expect from someone trying to get the password for one person's online banking account.
In short, if you're going to go this far, you might as well go down a different route that'll net more victims.As a result, this kind of anti-aliasing just isn't possible with a CRT. You can't really know, programatically, when each colour dots are going to be illuminated.
By comparison, LCDs have a 1:1 pixel colour component to screen pixel colour element mapping (assuming you're running it in full resolution of course, but if you have a 640x480 view stretched to fit a 1024x768 LCD screen then it's going to look pretty ugly regardless...), hence this trick works.
There's a difference between you being given unrestricted freedom to do whatever the hell you like, and you getting something you didn't have before. As we've all said before, the GPL gives you rights. You didn't have those rights before you agreed to the GPL. You may be able to find licenses that give you more rights, but that's irrelevent.
An EULA takes rights away. You started with fair use rights. If you agreed to an EULA, you agreed to waive those rights.
If you want to continue to argue this, please, show us a right the GPL takes away - and include the legal cite that says you had the right to it in the first place. Not "a license that gives you an additional right for a specific software product", a simple legal cite that says "By default, you have the right to X a copyrighted work, without agreeing to anything", and a place in the GPL where it says "You can't do X".
There is no real way to defeat HTTPS itself. You can try other types of hack to get the information, including the most popular user psychology type hacks, but on a technical level, HTTPS is (to the best of anyone's knowledge) secure. It does what it does.
In any case, my point was that the type of interception being suggested isn't practical. You can't break, in any of the ways described, HTTPS. You can install spyware, you can emulate a browser, you can do lots of things to get around the system, but you can't actually create a secure website that purports to be another in a generic, not exploting a specific browser's bug, way. That part is pretty solid. The types of DNS spoofing mentioned by the GGP aren't holes that the designers of HTTPS never thought of.
Remember: bankofslashdot.com will not send private keys, neither for the certificate nor for the session. Only public keys will be sent. The certificate will be signed by an authority. The session encryption key with the certificate.
You can't intercept the communications, suddenly switching the source of data. If you could, you wouldn't need to go to such extremes anyway because you could decode everything sent anyway, without the need for a fake server.
You can't take away a right you never had.
Understand that, and you understand why the GPL is not an EULA, and an EULA is an EULA. You start with the right to make backups for your own personal use, benchmark, reverse engineer, etc. These are all fair use. An EULA removes those rights, usually without granting any new ones.
You can't "fool" a certificate. The entire system is designed to check that the site claiming to be "www.bankofslashdot.org" really is "www.bankofslashdot.org". This is done not by checking IP addresses, but by ensuring that the site you're connecting to (a) has a signed certificate and (b) knows the private key part of that certificate.
If an attacker merely redirects browsers to a different web site, they'd still need the private part of that certificate, which is something they will not have. Why is that important? Because without the private part of the certificate, the spoof site cannot sign anything which means the browser will realise the site is fake immediately.
If an attacker tries to create a bogus certificate, for which they have the private part, they'll have problems getting it signed by any of the authorities whose keys are stored in every modern browser. (Want a list? Get Firefox [I don't have IE here so can't give the instructions for IE], check Preferences, Advanced, Certificates, Manage Certificates, Authorities.)
Unless the certificate is signed by an authority known to the browser, the browser will issue a warning, and while the average user might click through for unsigned certificates for "pr0n.net" or "fredsdiscountshop.com", they're sure as damn it not going to for their online banking. Indeed, in the latter case, the browser itself may actively prevent them from connecting if they've been to the site before and it had a legitimate, signed, certificate at that point.
There's no fooling the certificate. The certificate DOES NOT USE DNS. It associates a hostname with the certificate, but the entire point is to make sure that the machine that ultimately is connected to is the real thing, and the real thing could have any IP address.
You're saying, essentially, that the certificate system would be fooled by the very thing it was designed to prevent. It isn't. One of the primary reasons of designing it this way was to prevent this kind of attack. Otherwise, why store all the certs in a browser? It'd involve a hell of a lot less administration if we could just download the certificates automatically as we need them.
There are, obviously, alternatives. I think the best would be using VPNs if only the average WAP would include VPN servers supporting the sixty or so "standard" VPN systems so you didn't need additional hardware for that kind of thing.
No, read the explanation again. The MitM can pass on the certificate but they can't sign the session key with that certificate's private key 'cos they don't have it.
The GPL gives you additional rights not offered by default in copyright law. It doesn't require you do anything, it merely says "If you do such and such, in this kind of way, you're ok".
All of which is getting off-topic. The GPL is not an EULA, at least not usually (there are a lot of braindead installers out there I've noticed for OS X that force users to "Agree" to the GPL before installation, interestingly I wouldn't be surprised if non-copyright holders distributing such packages are actually violating the GPL by distributing it in such packages...
The GPL only grants rights. EULAs restrict them. The GPL says "You didn't have the right to do this before, you can now do this"; EULAs say "We don't care what copyright law says you can do, we're tearing up those rights and giving you an entirely new set."
Of course, geeks are more likely to implement WEP et al, thus making it 2% less likely you'll be hacked in this way.
The lesson isn't "Don't take candy from strangers", it's "Check that your mother really is your mother before accepting candy from here: always ask for ID. She may be someone who's taken cosmetic surgery to look like your mother."
Except that this particular situation is a little less improbable.
Keys and certificates have nothing to do with DNS, they're actually there to confirm that you really are connecting to a specific machine, not just a machine with the right IP address.
I don't know the exact technical details but I believe the process goes something like this:
Client: I want to make an HTTPS connection to your server www.bankofslashdot.org. Get the ball rolling by sending me your public key.
Server: Here it is. [String of several hundred binary digits follow]
Client: (Examines key) Ok, it's signed by Verisign, and it applies to www.bankofslashdot.org, the site I'm trying to connect to. Sounds good to me. Can you give me a session key I can use to encrypt information I send you?
Server: Here's the session key you're going to use, signed by my private key, which you can verify using the public key I just gave you
Client: (Encrypted) looks good, here's the session key you can use to send me information.
(In general RSA encryption is used. RSA is dual purpose, it can be used to sign information and to encrypt it. RSA keys have a public element and a private element. The public element can be used to encrypt information and verify signatures, but cannot be used to derive the private key. How does it work? Products of two very big prime numbers, don't ask me more than that 'cos I seriously don't know.)
A "man in the middle" would have a little bit of difficulty, as there's no way they could sign the session key they send to the client because that session key can only be signed if you have access to the private key, which they don't have.
If the key is invalid, or there isn't one signed by an authority to begin with (they're not compulsory), then browsers usually warn users.
The best I can think of is that you try to redirect a user to the wrong site. For example, the "Log in" button on http://www.bankofslashdot.org could redirect to https://www.blankofslashdot.org, though doing so would potentially expose the attacker as you have to prove you're real and you're the owner of the domain to most authorities to get a certificate for your key.
Anyone spotting obvious errors or wanting to fill in gaps in my explanation is most welcome to do so.
Given most DVDs are region encoded, regardless of whether they're for movies that came out in the cinema six months ago, or for movies that were released before video taping was ever invented, I think it's safe to say that region encoding doesn't really have a lot to do with cinema release dates.
If the radar says you have to stop, you have to stop. Regardless of who's behind you and what kind of utter idiot they are, you really have two choices - crash into what's in front, or put some trust in the driver behind you. There's only one logical answer to that.
This, incidentally, is also how it's recognized legally. Under most circumstances, in most of the juristictions I'm aware of (where all drivers are equal that is, there are some wierd racially-based driving rules in some countries too, but for the sake of argument, assume all other factors are equal) if someone brakes in front of you, even if it's just because they're an asshole, and you crash into them, you're the one at fault.
I suspect if we were to outlaw rear view mirrors tonight, whatever other types of accident may rise, the number of tailgaters would plummet and the number of accidents related to tailgating would do likewise. It's a shame banning rear view mirrors would probably cause more problems that it solves.
On the latter point, I always though it'd be interesting to write an OS that implemented signed executables, with a "valid" compiler being the thing that delivered the signatures. Then you'd implement all the VM handling in the compiler. Each program would be a little slower, but you'd have a rock solid no-app-can-crash-another-app type environment without needing hardware help.
There were, of course, bugs in the 68000, but the only two I remember were that it was possible for a user mode program to find out it was a user mode program, and that interrupts occured after an instruction was executed (which meant MMUs were impossible until the 68010, as you couldn't cleanly recover from a page fault with the original.)
Because it lacked memory protection, a program that crashed (or merely had a bug) had the potential to take down the system, but that's another matter. Essentially it depended on the crash.
In a cooperative multitasking environment, the program:
will bring down the computer. On the Amiga, such a program caused no damage whatsoever except slowing down the machine.In an environment without proper memory protection, the program:
will probably crash the computer (though it might not if, say, the stack is located just above the program itself, so causing the program to be the first thing wiped by the crash.)It's the lack of memory protection that's the problem with the Amiga.
That's good, although obviously there's also the links in the headers (like your http://ostermiller.org one) I suspect they're less suseptable to abuse because you can't link keywords to them by changing the text (the text is always the URL)
...and also make sure it only applies to the comment. .sigs and other user-created all-comment links should have NOFOLLOW in every link by default regardless of the moderation of the message. Otherwise it just helps the sell-your-soul-for-a-chance-at-a-free-iPod spammers.
I'd have thought that's obvious, but Slashdot psuedo-libertarians have a habit of confusing "can" and "should" these days.
But you'd agree with me, surely, that there's a difference between a construction company that employs by skill level and has no problem employing women who meet that criteria, and one that doesn't interview women without a note from a lawyer.
It's worth noting that in general discrimination lawsuits, those that aren't frivilous, rarely rely on employment mix figures. Indeed, where such mixes are mentioned, it's usually by the defense ("We can't possibly discriminate against women, why two of our senior managers are women!")
It's always a little eye opening reading the complaints and what provokes these kinds of lawsuits.