Edit your/etc/fstab. Comment out all mountpoints which say "swap" in the second column and reboot. Alternatively you may add "noauto" as an option for those mountpoints.
If you want to activate swap again on a live system, and your swap partition is/dev/hda6 for example, type:
If you run out of RAM without having swap, the same thing happens as when you run out of RAM when you have swap. The only difference is, it won't take ages before your system realizes there isn't enough space available.
Anyway, what happens is that a process is chosen by the Kernel to be killed off. Usually this is the process that has been making large memory requests recently and caused the out of memory condition. This goes very fast if you have no swap, you try to start the program and it will be killed halfway due to lack of memory. With swap, the same thing happens, but it takes much longer before the system "realizes" there's not enough space before killing the offending process.
There's really no need. I've been running several systems without swap for years now, even with high uptimes, and never did the lack of swap give any problems at all (well, Photoshop complains when you start it that there's no swap, but allows you to continue anyway). If you ever do think you need swap, it's possible to activate swap at any moment you please (goes for both Windows and Linux). You just need to reboot to turn it off again. I never ran into such a situation though, programs seem well-behaved these days and donot go allocating 1 GB chunks of RAM willy nilly just because they might need it later.
Memory managers do make louse decisions. Perhaps not in the case illustrated by the parent, but definitely in other ways. Best example are virus scanners. They scan every file over night, usually in a fairly slow fashion to not stress the I/O system too much. Memory managers will try and help out and swap out as much programs as possible in favor of the disk cache. Unfortunately, the memory manager does not realize this data is only accessed once (or is simply too much to complete cache for a second run of said virus scanner).
And that's something most people simply forget. Caching is ONLY effective if the data is:
1) Actually used more than once before it is discarded again. 2) Requested fast enough for it to become a bottleneck.
Examples of 1: Virus scanners, watching a large movie, copying large numbers of files. Is it likely any of those actions will benefit from caching because you might do it again right after performing that action?
Examples of 2: Any process that requests data in a slow but consistent manner. Uploading/downloading files, watching a movie, playing music files, a well-behaved virus scanner. All of these consume data at a speed that is below your maximum disk speed, in other words, the disk is not a bottleneck. The only reason to cache could be that this data might be needed again at higher speeds, but how likely is that to be the case? Does it really help that if I listen to an MP3 twice in a row that it is cached the second time?
It's assumptions are faulty. Let's assume for a second we have 1 GB of RAM. Per Oracle's guidelines I thus need 1 GB of Swap. I'm happy with this system and can do everything I want with it. It just sometimes feels a bit sluggish for some reason.
So... why not put 2 GB of RAM in it and then disable swap? I will use the system the same way as before and it works perfectly fine and never feels sluggish. However, suddenly Oracle's guidelines find that I need another 2 GB of Swap? Why?
It's because these guidelines assume that memory is expensive, and that it makes good sense to only buy as much as you absolutely need. Need in this case is defined as just enough to make the system usable and not be constantly bogged down by heavy swapping. The guidelines are based on the minimum amount of RAM you NEED, not on how much RAM you actually HAVE. Yes, it makes good sense to have as much swap available as the minimum amount of RAM you need to work comfortably. As soon however as you have much more RAM than what you really need, swap makes no sense at all.
Case in point: I recently upgraded a Linux System doing various tasks which had 2 GB RAM and no swap. I do everything with this machine, including posting here on Slashdot using a rather memory hungry tabbed browser. Never have I had problems with this configuration. The upgraded system however now contains 4 GB RAM. Why? Well, it was dirt-cheap, and I saw no reason to waste precious DIMM slots I may need in the future with newly bought 1 GB sticks. Think I need swap?
Let's assume for a second that my harddisk is just as fast as main memory. Does it make sense to cache this? Do you think memory managers make a distinction here? I know they don't.
So, what about the situation where my harddisk is not as fast as main memory, but instead I'm uploading a 4 GB file over night, at a rate of 1 MBps. Does it make sense to cache this 4 GB file? There's no hard disk stress on the system, other than some prefetching, there's no benefit at all from caching all this data that is being accessed only once. Do you think it likely this file will suddenly need to be accessed at top performance and thus benefitting from caching? What if the file is always accessed sequentially and is slightly larger than the total amount of RAM in your system? Does it make sense to try and cache the whole thing, knowing that it will never fit?
I'm afraid that memory managers aren't that smart, in fact, they're downright stupid. They donot KNOW what makes sense to cache, they just use highly tweaked LRU type algorithm and don't pay any attention to usage patterns and whether or not the underlying media would benefit from caching for a given task. So they will do stupid things, like trying to cache a 4 GB data file which was uploaded the other night. This leaves you with a crippled system in the morning because it decided to slowly swap out everything during the night for this purpose.
The question then is, will swapping out 500 MB of programs on a 4 GB system result in any tangible benefits for the disk cache, or rather in user frustration when those apps are getting swapped back in...
Second, swap can be VERY useful even if you NEVER run out of ram. The OS can swap apps that have used memory but aren't actually doing anything with it out, and leave that memory available for file/disk caching, which can make performance FAR better than if you kept the idling apps in memory and had less available disk cache. Some apps avoid buffering things in memory because its both easier and most times more efficient to use the disk and let the OS manange the buffering. I've seen NT based OSes aggressively swap out things that aren't in use just so there is more memory available for disk cache, and it makes sense cause there is a lot of crap the kernel and other apps load up that is very RARELY needed, if ever.
Unfortunately, these "aggressive" memory managers are rather stupid. They will happily swap out every running program to increase the disk cache even in situations where caching makes no sense. Caching only makes sense if the underlying media is a bottleneck for performing a given task. How much of a bottleneck is your hard disk however when you are downloading and uploading files? When you're watching a movie? When you're playing MP3's? Or even, when you are serving web pages (over a link slower than your hard disk)?
In none of those situations will you get ANY benefit at all from disk caching... yet if I watch a 4 GB movie over a period of 2 hours, a lot of memory managers will decide that attempting to cache all of that data might be a good thing. Halfway through the movie, it will think that all those other running programs have been unused for an hour and can be safely swapped out in favor of caching more of that 4 GB file. The end result is that half your programs are swapped out after watching a movie, resulting in a sluggish system that is trashing all over the swap file to restore some sanity to it, and all for caching data that put NO STRESS on the underlying media in the first place.
The same thing happens for idling systems left on over night, doing simple tasks like virus scanning, downloading files, rebuilding indexes, and so on. The end result is that a system feels sluggish the next day, for no tangible performance benefit.
Ask yourself, if I have 4 GB of RAM, and 500 MB worth of applications running, effectively having 3.5 GB for disk caching. How useful is it to swap out that extra 0.5 GB worth of kernel/programs for even more disk caching? Is 4 GB of disk cache so much more valuable than 3.5 GB? I highly doubt it, so to prevent stupid memory managers from swapping out my favourite programs which I left running for a reason, I just turn off swap.
This formula is ridiculous and makes no sense at all. To determine if you need swap you are far better off just figuring out if your system has enough RAM to run the programs you want to use on a daily basis. If you have that, then there's no reason to ever use swap (as that was the original reason people needed swap in the first place). As an added bonus, systems without swap cannot swap out programs in favor of increasing the disk cache, keeping everything snappy even after days of not using certain programs. So, here's my formula:
1) Donot turn on swap. 2) If there's ever any problem with memory, create a swap file (if you don't have one yet) and type swapon on a live system.
You can see when you have a memory problem by applications getting killed when they try to allocate large chunks of memory or by keeping an eye on a memory monitor. If you see most memory allocated to stuff that isn't the disk cache, then you'll need swap.
I know exactly what the difference is. What you donot seem to grasp is that adding JUST encryption to a plain HTTP session that makes ZERO claims about security, is STILL a bonus. It prevents casual snooping. It prevents deep packet inspection by your provider. It raises the bar for anyone trying to get your personal information.
It does not have to be displayed as secure, it does not make any claims to be secure, it makes the same claims as HTTP. Yet, HTTP is allowed free reign, while HTTPS + self-signed certificates is billed as being even worse than just sending everything in plain text.
What your problem is is that for some reason you think there's just one problem possible on the internet: Talking to the WRONG person. There's however also network snoopers, deep packet inspection, compromised routers that will gather information send in plain text, and so on. The chances of the first to occur (talking to the wrong person) are FAR smaller (and FAR harder to execute) than just snooping a connection for plain text conversations. The latter scenarios can however be eliminated by simply using encryption, raising the bar high enough that any casual snooper will be deterred.
All most self-signed certificate using sites want is to eliminate plain text conversations, just plain simple encryption, they make no claims about security, they don't want a "green bar", they just don't want to be treated as worse than HTTP.
Your browser can STILL check if the certificate changed, and then put up a warning instead of accepting a NEW or CHANGED certificate for the same site.
Which is exactly what HTTP does, it provides you with a false sense of security (as in, no warnings at all), while a slightly more secure solution is billed as something you must avoid like the plague.
Self-signed certificates should be accepted automatically and displayed and treated as a regular HTTP site. No green status bar. Issue a warning though if the certificate changed.
Self-signed certificates should be accepted automatically, there should not be ANY conditioning involved at all.
That way when a real problem occurs (like a certificate that changed, or claiming to be issued by some authority but really wasn't), then you can provide a warning that users won't have been trained to ignore.
Accepting self-signed certificates automatically is no less secure than issuing no warnings when you go to a normal HTTP page. They're both open to all kinds of problems. Then why is one being treated like the biggest evil there is and the other is just given a "normal looking status bar" and allowed to go about its business?
The only thing you should change is that a self-signed certificate does not display the green status bar and lock, just make it look like a normal every day HTTP site, accept it automatically, and only warn the user if the certificate changed since last visit.
Let's say we have two websites. They both do the same thing, they allow you to type in your current location and then show you a local weather report.
Website 1: Uses plain HTTP. Your assessment: Seems OK. Website 2: Uses self-signed certificate to provide encryption. Your assessment: Something fishy is going on.
Both only display a weather report. One however provided you with the added bonus that people couldn't see that you actually requested the weather report at a location in Afghanistan. Nothing special, it's just an added bonus.
There's four levels of security currently in browsers:
1) SSL certificates signed by some "trusted" authority. Such a certificate is impossible to obtain by criminals.. oh wait, that's bullshit, let's say it like it really is: Such a certificate is impossible to obtain by people without money.
- It prevents your little brother from snooping on your network - It will issue a warning if the certificate was changed since last time you visited - It gives you a good feeling
Claimed Security level: 100% secure, no warnings of any kind Actual Security level: Nothing a determined hacker couldn't get around
2) SSL certificates that are self-signed. Anyone can make them.
- It prevents your little brother from snooping on your network - It will issue a warning if the certificate was changed since last time you visited
Claimed Security level: Totally insecure, requires four clicks to get around Actual Security level: Nothing a determined hacker couldn't get around, but at least safe from casual hackers
3) Plain HTTP
- It prevents your little brother from snooping on your network - It will issue a warning if the certificate was changed since last time you visited
Claimed Security level: 100% secure, no warnings of any kind. Actual Security level: It's plain text, even a trained monkey could see what I'm typing.
4) No HTTP
Claimed Security level: 100% secure, no warnings of any kind. Actual Security level: It really is 100% secure.
Gosh, you are so smart. Perhaps I installed that self-signed cert on my router myself (after all it is my router), and then when I access my router I like, you know, CHECK if it is MY self-signed certificate, and not something that was replaced by some hacker. The really good browsers will even warn you when the certificate changed again!
You'd almost have everyone believe that self-signed certificates are somehow bogus and can be hacked at will, while in reality that's just FUD.
No, they are not. I'm afraid you are not as experienced as you think.
You see, self-signed certificates are only wide open to MITM attacks if the person monitoring you was replacing all certificates pro-actively before you even visited the website once. If you however have visited the site before, Firefox will warn you that the certicate has changed when a MITM changes it. At this point Firefox should display a big red warning.
Furthermore, and this is the part that people like you donot seem to grasp, there IS use for encryption beyond protection from MITM attacks. Using SSL encryption protects me from password sniffers that sit on my network, or in my wireless neighbourhood or from some comprimised router my request travels over. It protects me from some script kiddy running a network monitor seeing what I'm typing in HTTP forms. Yes, it does not protect me from a REAL MITM attack (unless of course I've been there before, and see that the certicate changed), however the sites providing simple SSL encryption just for the sake of not sending stuff in plain text are not worth attacking anyway.
Those people using self-signed certificates could also simply run a normal HTTP server, and you'd be none the wiser. You donot get warnings for "regular" HTTP sites.
You are basically saying that a website with an expired certificate or self-signed certificate is WORSE than regular HTTP sites, while in reality they atleast provide you with an encrypted connection and a warning if the certificate changed since the last time you connected to that site (and when that happens, THEN you should get a BIG RED WARNING).
2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.
Oh... is it that cheap to buy security these days? I never realized criminals couldn't afford it.
Slashdot Mirror
You do realize Windows 7 won't be something new but is just Vista with a new name and a somewhat bigger than normal service pack?
Need I say more?
Not even Windows crashes from out of memory conditions anymore these days. It will also kill the process deemed most offending and continue.
Edit your /etc/fstab. Comment out all mountpoints which say "swap" in the second column and reboot. Alternatively you may add "noauto" as an option for those mountpoints.
If you want to activate swap again on a live system, and your swap partition is /dev/hda6 for example, type:
#> swapon /dev/hda6
If you run out of RAM without having swap, the same thing happens as when you run out of RAM when you have swap. The only difference is, it won't take ages before your system realizes there isn't enough space available.
Anyway, what happens is that a process is chosen by the Kernel to be killed off. Usually this is the process that has been making large memory requests recently and caused the out of memory condition. This goes very fast if you have no swap, you try to start the program and it will be killed halfway due to lack of memory. With swap, the same thing happens, but it takes much longer before the system "realizes" there's not enough space before killing the offending process.
There's really no need. I've been running several systems without swap for years now, even with high uptimes, and never did the lack of swap give any problems at all (well, Photoshop complains when you start it that there's no swap, but allows you to continue anyway). If you ever do think you need swap, it's possible to activate swap at any moment you please (goes for both Windows and Linux). You just need to reboot to turn it off again. I never ran into such a situation though, programs seem well-behaved these days and donot go allocating 1 GB chunks of RAM willy nilly just because they might need it later.
Memory managers do make louse decisions. Perhaps not in the case illustrated by the parent, but definitely in other ways. Best example are virus scanners. They scan every file over night, usually in a fairly slow fashion to not stress the I/O system too much. Memory managers will try and help out and swap out as much programs as possible in favor of the disk cache. Unfortunately, the memory manager does not realize this data is only accessed once (or is simply too much to complete cache for a second run of said virus scanner).
And that's something most people simply forget. Caching is ONLY effective if the data is:
1) Actually used more than once before it is discarded again.
2) Requested fast enough for it to become a bottleneck.
Examples of 1: Virus scanners, watching a large movie, copying large numbers of files. Is it likely any of those actions will benefit from caching because you might do it again right after performing that action?
Examples of 2: Any process that requests data in a slow but consistent manner. Uploading/downloading files, watching a movie, playing music files, a well-behaved virus scanner. All of these consume data at a speed that is below your maximum disk speed, in other words, the disk is not a bottleneck. The only reason to cache could be that this data might be needed again at higher speeds, but how likely is that to be the case? Does it really help that if I listen to an MP3 twice in a row that it is cached the second time?
It's assumptions are faulty. Let's assume for a second we have 1 GB of RAM. Per Oracle's guidelines I thus need 1 GB of Swap. I'm happy with this system and can do everything I want with it. It just sometimes feels a bit sluggish for some reason.
So... why not put 2 GB of RAM in it and then disable swap? I will use the system the same way as before and it works perfectly fine and never feels sluggish. However, suddenly Oracle's guidelines find that I need another 2 GB of Swap? Why?
It's because these guidelines assume that memory is expensive, and that it makes good sense to only buy as much as you absolutely need. Need in this case is defined as just enough to make the system usable and not be constantly bogged down by heavy swapping. The guidelines are based on the minimum amount of RAM you NEED, not on how much RAM you actually HAVE. Yes, it makes good sense to have as much swap available as the minimum amount of RAM you need to work comfortably. As soon however as you have much more RAM than what you really need, swap makes no sense at all.
Case in point: I recently upgraded a Linux System doing various tasks which had 2 GB RAM and no swap. I do everything with this machine, including posting here on Slashdot using a rather memory hungry tabbed browser. Never have I had problems with this configuration. The upgraded system however now contains 4 GB RAM. Why? Well, it was dirt-cheap, and I saw no reason to waste precious DIMM slots I may need in the future with newly bought 1 GB sticks. Think I need swap?
Let's assume for a second that my harddisk is just as fast as main memory. Does it make sense to cache this? Do you think memory managers make a distinction here? I know they don't. So, what about the situation where my harddisk is not as fast as main memory, but instead I'm uploading a 4 GB file over night, at a rate of 1 MBps. Does it make sense to cache this 4 GB file? There's no hard disk stress on the system, other than some prefetching, there's no benefit at all from caching all this data that is being accessed only once. Do you think it likely this file will suddenly need to be accessed at top performance and thus benefitting from caching? What if the file is always accessed sequentially and is slightly larger than the total amount of RAM in your system? Does it make sense to try and cache the whole thing, knowing that it will never fit? I'm afraid that memory managers aren't that smart, in fact, they're downright stupid. They donot KNOW what makes sense to cache, they just use highly tweaked LRU type algorithm and don't pay any attention to usage patterns and whether or not the underlying media would benefit from caching for a given task. So they will do stupid things, like trying to cache a 4 GB data file which was uploaded the other night. This leaves you with a crippled system in the morning because it decided to slowly swap out everything during the night for this purpose.
The question then is, will swapping out 500 MB of programs on a 4 GB system result in any tangible benefits for the disk cache, or rather in user frustration when those apps are getting swapped back in...
Unfortunately, these "aggressive" memory managers are rather stupid. They will happily swap out every running program to increase the disk cache even in situations where caching makes no sense. Caching only makes sense if the underlying media is a bottleneck for performing a given task. How much of a bottleneck is your hard disk however when you are downloading and uploading files? When you're watching a movie? When you're playing MP3's? Or even, when you are serving web pages (over a link slower than your hard disk)?
In none of those situations will you get ANY benefit at all from disk caching... yet if I watch a 4 GB movie over a period of 2 hours, a lot of memory managers will decide that attempting to cache all of that data might be a good thing. Halfway through the movie, it will think that all those other running programs have been unused for an hour and can be safely swapped out in favor of caching more of that 4 GB file. The end result is that half your programs are swapped out after watching a movie, resulting in a sluggish system that is trashing all over the swap file to restore some sanity to it, and all for caching data that put NO STRESS on the underlying media in the first place.
The same thing happens for idling systems left on over night, doing simple tasks like virus scanning, downloading files, rebuilding indexes, and so on. The end result is that a system feels sluggish the next day, for no tangible performance benefit.
Ask yourself, if I have 4 GB of RAM, and 500 MB worth of applications running, effectively having 3.5 GB for disk caching. How useful is it to swap out that extra 0.5 GB worth of kernel/programs for even more disk caching? Is 4 GB of disk cache so much more valuable than 3.5 GB? I highly doubt it, so to prevent stupid memory managers from swapping out my favourite programs which I left running for a reason, I just turn off swap.
This formula is ridiculous and makes no sense at all. To determine if you need swap you are far better off just figuring out if your system has enough RAM to run the programs you want to use on a daily basis. If you have that, then there's no reason to ever use swap (as that was the original reason people needed swap in the first place). As an added bonus, systems without swap cannot swap out programs in favor of increasing the disk cache, keeping everything snappy even after days of not using certain programs. So, here's my formula:
1) Donot turn on swap.
2) If there's ever any problem with memory, create a swap file (if you don't have one yet) and type swapon on a live system.
You can see when you have a memory problem by applications getting killed when they try to allocate large chunks of memory or by keeping an eye on a memory monitor. If you see most memory allocated to stuff that isn't the disk cache, then you'll need swap.
One wonders what Youtube would do when a non-American citizen sends out a few DMCA notices... this just seems way to easy.
You should perhaps spend a few years of your live pondering that question.
I know exactly what the difference is. What you donot seem to grasp is that adding JUST encryption to a plain HTTP session that makes ZERO claims about security, is STILL a bonus. It prevents casual snooping. It prevents deep packet inspection by your provider. It raises the bar for anyone trying to get your personal information.
It does not have to be displayed as secure, it does not make any claims to be secure, it makes the same claims as HTTP. Yet, HTTP is allowed free reign, while HTTPS + self-signed certificates is billed as being even worse than just sending everything in plain text.
What your problem is is that for some reason you think there's just one problem possible on the internet: Talking to the WRONG person. There's however also network snoopers, deep packet inspection, compromised routers that will gather information send in plain text, and so on. The chances of the first to occur (talking to the wrong person) are FAR smaller (and FAR harder to execute) than just snooping a connection for plain text conversations. The latter scenarios can however be eliminated by simply using encryption, raising the bar high enough that any casual snooper will be deterred.
All most self-signed certificate using sites want is to eliminate plain text conversations, just plain simple encryption, they make no claims about security, they don't want a "green bar", they just don't want to be treated as worse than HTTP.
Your browser can STILL check if the certificate changed, and then put up a warning instead of accepting a NEW or CHANGED certificate for the same site.
Which is exactly what HTTP does, it provides you with a false sense of security (as in, no warnings at all), while a slightly more secure solution is billed as something you must avoid like the plague.
Self-signed certificates should be accepted automatically and displayed and treated as a regular HTTP site. No green status bar. Issue a warning though if the certificate changed.
Self-signed certificates should be accepted automatically, there should not be ANY conditioning involved at all.
That way when a real problem occurs (like a certificate that changed, or claiming to be issued by some authority but really wasn't), then you can provide a warning that users won't have been trained to ignore.
Accepting self-signed certificates automatically is no less secure than issuing no warnings when you go to a normal HTTP page. They're both open to all kinds of problems. Then why is one being treated like the biggest evil there is and the other is just given a "normal looking status bar" and allowed to go about its business?
The only thing you should change is that a self-signed certificate does not display the green status bar and lock, just make it look like a normal every day HTTP site, accept it automatically, and only warn the user if the certificate changed since last visit.
Let's say we have two websites. They both do the same thing, they allow you to type in your current location and then show you a local weather report.
Website 1: Uses plain HTTP. Your assessment: Seems OK.
Website 2: Uses self-signed certificate to provide encryption. Your assessment: Something fishy is going on.
Both only display a weather report. One however provided you with the added bonus that people couldn't see that you actually requested the weather report at a location in Afghanistan. Nothing special, it's just an added bonus.
There's four levels of security currently in browsers:
1) SSL certificates signed by some "trusted" authority. Such a certificate is impossible to obtain by criminals.. oh wait, that's bullshit, let's say it like it really is: Such a certificate is impossible to obtain by people without money.
- It prevents your little brother from snooping on your network
- It will issue a warning if the certificate was changed since last time you visited
- It gives you a good feeling
Claimed Security level: 100% secure, no warnings of any kind
Actual Security level: Nothing a determined hacker couldn't get around
2) SSL certificates that are self-signed. Anyone can make them.
- It prevents your little brother from snooping on your network
- It will issue a warning if the certificate was changed since last time you visited
Claimed Security level: Totally insecure, requires four clicks to get around
Actual Security level: Nothing a determined hacker couldn't get around, but at least safe from casual hackers
3) Plain HTTP
- It prevents your little brother from snooping on your network
- It will issue a warning if the certificate was changed since last time you visited
Claimed Security level: 100% secure, no warnings of any kind.
Actual Security level: It's plain text, even a trained monkey could see what I'm typing.
4) No HTTP
Claimed Security level: 100% secure, no warnings of any kind.
Actual Security level: It really is 100% secure.
Gosh, you are so smart. Perhaps I installed that self-signed cert on my router myself (after all it is my router), and then when I access my router I like, you know, CHECK if it is MY self-signed certificate, and not something that was replaced by some hacker. The really good browsers will even warn you when the certificate changed again!
You'd almost have everyone believe that self-signed certificates are somehow bogus and can be hacked at will, while in reality that's just FUD.
No, they are not. I'm afraid you are not as experienced as you think.
You see, self-signed certificates are only wide open to MITM attacks if the person monitoring you was replacing all certificates pro-actively before you even visited the website once. If you however have visited the site before, Firefox will warn you that the certicate has changed when a MITM changes it. At this point Firefox should display a big red warning.
Furthermore, and this is the part that people like you donot seem to grasp, there IS use for encryption beyond protection from MITM attacks. Using SSL encryption protects me from password sniffers that sit on my network, or in my wireless neighbourhood or from some comprimised router my request travels over. It protects me from some script kiddy running a network monitor seeing what I'm typing in HTTP forms. Yes, it does not protect me from a REAL MITM attack (unless of course I've been there before, and see that the certicate changed), however the sites providing simple SSL encryption just for the sake of not sending stuff in plain text are not worth attacking anyway.
Unfortunately, you donot get it at all.
Those people using self-signed certificates could also simply run a normal HTTP server, and you'd be none the wiser. You donot get warnings for "regular" HTTP sites.
You are basically saying that a website with an expired certificate or self-signed certificate is WORSE than regular HTTP sites, while in reality they atleast provide you with an encrypted connection and a warning if the certificate changed since the last time you connected to that site (and when that happens, THEN you should get a BIG RED WARNING).
Arguably, sites that use SSL are more secure than regular HTTP sites. Why then are no big red warnings displayed for every regular HTTP site visited?
Oh... is it that cheap to buy security these days? I never realized criminals couldn't afford it.