a) there is really nobody to compete against b) no more unlimited funds like in good old cold war days
The direct consqeunce of a) and b) is that political will to put human life at risk just to stick a flagpole in middle of a desert (before the Russians do it) is way lower than back in '60s and '70s.
Welcome to the real world. It is not just the government. Every large organization works that way. Including multi-billion dollar corporations.
If you don't spend your budget, whoever controls it will cut it down. If it gets cut, it is extremely hard (next to impossible) to get it increased when you really need it. So, there's an excellent incentive for "budget burning".
A lot of difference. Any script kiddie out there would be able to invalidate caches rather quickly. Anyhow, how exactly is the client supposed to know why the connection was not successfull? It might have nothing to do with DNS. Service might be down, or he might be attempting to access the service server is not offering.
The only good solution is to stop ISPs from playing with TTL. The bandwith they are saving is so marginal, it simply isn't worth it.
You sure you tested it correctly? You did change serial numbers each time you changed your zone info? If you haven't, than DNS server you were testing detected that serial number hasn't changed, and did the right thing (continumed to use cached copy for next TTL period of time). The thing that remote DNS picked up the change eventually (after several weeks, or after you opened ticket with ISP) might be simply due to the fact they restarted DNS server (which would discard all cached entries).
If your test was performed correctly, than overriding TTL certanly breaks number of things. As most people already noted, experienced system admins will temporarely set TTL low for their domains in preparation for big changes (and raise it once the changes are done).
Another thing that will break is dynamic DNS. Dynamic DNS uses low TTL (sometimes as low as one minute, or even several seconds) since A records are pointing to IP addresses that change on daily (sometimes hourly, or even shorter) basis. Anybody using any form of dynamic DNS would be hit by this very hard.
Of course, it also opens a whole bunch of security related issues, for domains that are managed by dynamic DNS services, and/or users (big and small) with static IP addresses when they are switching providers (which usually includes new set of IP addresses being assigned).
You know, there's a reason why soldiers do not have access to live ammo as they wish when not on duty. There's also a reason why soldiers are not allowed to take their M16 (or AK-47, depending in what army they are) with them when going to the town (to get drunk).
I've been in army. I've been at university. The only difference is, in the army there's always somebody who supervises (and brainwashes) those kids. That's the reason you get less bullshit in the army. Responsibility has nothing to do with it.
BTW, your numbers are wildly exegerated. In my experience, you have about 1 in 100 kids doing something really stupid and dangerous in the army, and about 1 in 100 kids doing something really stupid and dangerous in the college/university.
Sorry. I've been in army when I was 18. And I can tell you, 18 year old in the army with live ammo and grenades are no more resopnsible than 18 year old in college. They do stupid things. And they get up the shit creek without paddle. On regular basis. Occasionaly, somebody gets hurt or even killed.
Army is not as organized as it may seem on the surface. And once you send those 18 years old to some far away country, and they blow up a bus full of high school kids, nobody cares back home. And they don't get up shit creek without paddle. After all they were fighting for their country.
There are reasons army prefers 18 years old over 38 years old. And responsibility is not one of them. Frankly, if the army could get away with recruiting 16 or 14 years old kids, they would do it.
The idea is that 18-years old is stupid enough to make a choice of getting killed. Period. No additional patriotic bullshit. And even more stupid to make a choice of killing other people ("for his country", as you said).
Come on people. Linus told long ago it chosed Larry's tool because there was nothing in open source world that was nearly as good. And 2.6 kernel and the speed it was being developed is more than enough proof of that.
On the other side, Larry made a deal. And he made a really good deal. Too bad it wasn't enforcable (both for him and Linus). I'll give you the best tool that exists on the planet for free, and in exchange you are not going to reverse engineer the protocol it uses. You can develop competing tool with its own protocol, though. This sounds like a good deal for open source comunity too. If anybody cares what I think about it. Open source comunity got a freebie.
So, while there is nothing unethical about reverse engineering the protocol, it is unethical not to keep the word you gave. If Larry struck the deal with real organization ("organizatoin" in legal sense of the word, as in legal entity), he could as well go to court and win. Easily. Luckily, it is virtually impossible to sue "open source comunity". Who exactly are you going to sue?
If anybody wants to hear my opinion, it was more than clear that somebody is going to backstab Linus and do exactly what Tridgel did. Come on people, Tridgel knew exactly what he was doing. Deal between Linus and Larry wasn't a big secret. It was spelled in big words: you may use it for free as long as nobody attempts to reverse engineer the protocol.
Deals are deals. When somebody breaks it, there is no deal anymore. It is that simple. You may be religious about the issues involved. You may be emotional. Or you may be cool headed. Whatever way you choose to react, you can't change simple facts.
And for those saying that adding HTML does not waste bandwith, just consider this. I've created one-liner "Let's test bold stuff", with only single word "bold" in bold on GMail. Sent it. It created multipart/alternative email. First part was plain text. Second part was HTML. HTML part was 2.48 times in size of text part! Nice. And no, Google's idea of specifying something is bold is not good old "b" tag. They are fancier than that.
Counting the headers and everything else, the resulting multipart/alternative email was 30% larger than it would be if it was text-only. 30% larger, just to have single word bold in one-liner email! For larger emails where header/content ratio is lower, this would get even worse (closer to 100%, and for a bit longer texts such as this one probably well over double in size).
Now, one might say "who cares, I have 2GB for email". Well, news for you, I have 150GB (would have 300GB if it wasn't for the RAID1). I want to use that 150GB to be able to keep more email for longer time (which is basically idea behind GMail). Me, and everybody else who shares that 150GB of disk space with me. Not to store less email for shorter period of time.
And yes, vast majority of people will overdo things when you give them control over fonts, and will make texts look way worse than if they were simply plain text. The truth is, if something looks like it should be in bold, most likely it doesn't need to be. And if anybody cares to check typesetting hints and tips for making readable text, they say: use one font and stick with it in entire document, use special stuff (bold, italics) rarely and wisely.
Check your local newspapers, or grab any book from your bookshelf, and you'll see what I'm talking about. Than compare it to average HTML email. And see the difference.
BTW, would somebody explain to me why is specifying numbered list in HTML more readable then:
1. foo 2. bar 3. foobar
in plaintext?
Or why are bullets more readable than:
- one
- two
- three
Somehow I fail to see the difference.
Well, enough complaining. Time to finally modify my mimedefang-milter to drop all text/html parts. I need only one copy of what somebody wrote. Not two. Considering that more and more people are using GMail for mailing lists, my private mailing list archives are going to literary explode. Wish there was a way to prevent wasting my bandwith in the first place.
Re:I got Password Safe but what about my swap file
on
ID Theft Made Easy
·
· Score: 1
There's no way around it. Apperently there is a system call in Windows that application can use to request a memory page not to be swapped out, however it doesn't guarantee that the page will not be swapped out (unlike Unix memory lock, that actually locks the page into the memory). For more details, check discussions about it in GnuPG documentation/archives. Even if there was a way to prevent a memory page (containing your password) to be locked into the memory this way, obviously it would be application's responsibility to use it. I'm not aware of any web browser on Unix that actually use memory locking for memory pages that contain passwords (if there were, they would need to be setuid root in order to use the feature, which might be even worse scenario).
I don't know of any easy way of encrypting Windows swap file. The only system I used that has out of box, easy to use encryption of swap was OpenBSD (and probably other similar *BSD variants).
Overwriting swap file with zeros on reboots isn't going to save you either. Depending on how determined and resourcefull attacker is, information from "overwritten" disk blocks can be more or less easily retrieved (probably almost any university has equipment needed for that handy, and apperently it isn't that expensive either nowdays). Overwriting with several "special" patterns might help, but if NSA doesn't trust that method, why should you.
It is the system that makes ID theft possible
on
ID Theft Made Easy
·
· Score: 1
It is the system that makes ID theft possible. The system is made to be too transparent to the consumer instead of secure. Back in my home country, no bank would open and account or perform any other action or give out information simply because the person requesting it can answer couple of trivial questions such as date of birth and/or approximate account balance and with no ID checks at all. And that was long before ID theft become so big problem here in North America.
Does this cripples things such as telephone banking? Sure it does, if for anything non-trivial you need to show in person at counter with government issued photo-ID. But at least your money isn't going to end up in Nigeria overnight.
I was shoked after I moved to North America and found out that I can get credit card by simply making a phone call and simply telling the service representative on the other side my date of birth and answers to couple of other trivialities... Shees. Wake up folks. The system that is currently in place is a paradise for criminals.
Yes, you can use rlimit to limit some things. However, some limits are not completely implemented in Linux. For example, there is no way to effectively limit the number of virtual pages resident in RAM for a single process. The setrlimit for RLIMIT_RSS will only affect portions of memory where madvise was applied with MADVISE_WILLNEED (as per setrlimit manual page you mentioned).
I so totally do not agree with what you wrote. The operating system should protect itself and other processes from a single process going mad. If you don't have that as integral part of the OS, than why botter developing new stuff? We could all stayed with MS-DOS and Windows 3.11. Remember what was the most common objection to that combo? Single application goes bad, and entire system goes down. Same thing with fork bombs or any other implementation of "let make machine really busy doing something stupid, so that everything else on the system is brought to the halt". OS that dosn't have this kind of protections in place is, sorry but, really no better than DOS/Win3.11 combo.
Kernel efficiently protecting it's memory space is trivial to implement. It just uses something that already exists in hardware. Kernel that does more than that, well obviously it takes a bit more work...
Create huge sparse file (say 1 gig). mmap it into the memory. memset on 1 gig region. You don't even have to do it in a loop. Makes a big trouble if you have 256 or less RAM. And you don't need a loop either. If you do madvise prior to memset on that region with carefully selected advise value, all you can do is turn off the machine (or wait for a quite a long time for machine to recover). Now put that into loop;-)
There's more ways to kill Linux box from user space. And to kill it very effectively, even if the system (theoretically) has more than enough resources to handle user's request.
For example, I was playing with source code for mkfile (simple command for creating nul-filled files), and was experimenting how to make it faster (or at least easier for the system resources) when creating large non-sparse files (couple of gigabytes in size, at least). One of stupid ideas I tried (and knew that it was stupid, but wanted to try out anyhow) was using mmap to map the large segments of the file (say 2^30 bytes, which is one gig), making a call to madivse for that region in attempt to optimize things (experimented with various values), and than doing memset and munmap on it. Run it to create 10 gig file. Guess what. Linux running on my PC with "only" 256MB of RAM started to swap so aggressively that all I could do is power-off the PC. I couldn't swith out of X to text console. SSH session from another machine was totaly dead. The machine was totaly dead, completely frozen. Except the disk light that was on. Single process that needs to swap a lot. And machine is *totally* dead.
Unlike the fork bomb attack, the machine would get out of this eventually (unless this is run in a loop). Probably in couple of hours. Or by the next day. I hadn't that much time on my hands, so I powered it off, and on again. Back to the drawing table.
I knew that what I coded wasn't smart, but to trash machine like that....
Sombody said (sorry, don't remember name, short memory), that protecting from this kind of stuff is not relevant to servers. I don't agree. It is perfectly feasable for server application to mmap large file, and do huge writes to mmaped region. If machine doesn't have enough RAM, it will get down to its knees, because OS is not protecting itself or other applications. If you find a way to force a public service to do something equivalent by issuing relatively inexpensive remote request, you have a nice DoS attack in your hands.
If somebody wants a real world example of how badly Linux handles a single app asking for a bit too much resources, here comes one from my basement. There's one old machine I use as web server, proxy server and cyrus imapd. It is an old machine, Pentium MMX, 96 megs RAM. For two user accounts, it works perfectly, and more than fast enough. Run "yum update", and things simply fall apart. It becomes completely unresponsive. Reason? Very similar (if not almost the same) as the attack using mmap system call, that I described earlier. Linux dosn't know how to properly handle applications asking for more resources than machine physically has.
I kind of agree with you. If person/organization requesting patent is unable to provide documentation that it invested considerable amount of time and resources in development, it shouldn't be granted a patent. Period. Patents shouldn't be lottery tickets (as they are today, sadly). They are supposed to give incentive for serious (and costly) development efforts. The way they are granted today (especially software patents) is a joke.
Slashdot Mirror
This time it will take 15 years because:
a) there is really nobody to compete against
b) no more unlimited funds like in good old cold war days
The direct consqeunce of a) and b) is that political will to put human life at risk just to stick a flagpole in middle of a desert (before the Russians do it) is way lower than back in '60s and '70s.
You missed the point.
They got a patent on something obvious and logical. There's no inovation there. And there even might be some previous art.
I mean, come on. Even my home alarm has couple of buttons with icons for ambulance, firefighters and police. They simply added touchscreen to it.
Or what about those diagrams for emergency situations you find in some buildings or haning in hotel rooms? Essentially they are the same thing.
IMO, this is classic example of abuse of patent system.
Welcome to the real world. It is not just the government. Every large organization works that way. Including multi-billion dollar corporations.
If you don't spend your budget, whoever controls it will cut it down. If it gets cut, it is extremely hard (next to impossible) to get it increased when you really need it. So, there's an excellent incentive for "budget burning".
A lot of difference. Any script kiddie out there would be able to invalidate caches rather quickly. Anyhow, how exactly is the client supposed to know why the connection was not successfull? It might have nothing to do with DNS. Service might be down, or he might be attempting to access the service server is not offering.
The only good solution is to stop ISPs from playing with TTL. The bandwith they are saving is so marginal, it simply isn't worth it.
You sure you tested it correctly? You did change serial numbers each time you changed your zone info? If you haven't, than DNS server you were testing detected that serial number hasn't changed, and did the right thing (continumed to use cached copy for next TTL period of time). The thing that remote DNS picked up the change eventually (after several weeks, or after you opened ticket with ISP) might be simply due to the fact they restarted DNS server (which would discard all cached entries).
If your test was performed correctly, than overriding TTL certanly breaks number of things. As most people already noted, experienced system admins will temporarely set TTL low for their domains in preparation for big changes (and raise it once the changes are done).
Another thing that will break is dynamic DNS. Dynamic DNS uses low TTL (sometimes as low as one minute, or even several seconds) since A records are pointing to IP addresses that change on daily (sometimes hourly, or even shorter) basis. Anybody using any form of dynamic DNS would be hit by this very hard.
Of course, it also opens a whole bunch of security related issues, for domains that are managed by dynamic DNS services, and/or users (big and small) with static IP addresses when they are switching providers (which usually includes new set of IP addresses being assigned).
You know, there's a reason why soldiers do not have access to live ammo as they wish when not on duty. There's also a reason why soldiers are not allowed to take their M16 (or AK-47, depending in what army they are) with them when going to the town (to get drunk).
I've been in army. I've been at university. The only difference is, in the army there's always somebody who supervises (and brainwashes) those kids. That's the reason you get less bullshit in the army. Responsibility has nothing to do with it.
BTW, your numbers are wildly exegerated. In my experience, you have about 1 in 100 kids doing something really stupid and dangerous in the army, and about 1 in 100 kids doing something really stupid and dangerous in the college/university.
Sorry. I've been in army when I was 18. And I can tell you, 18 year old in the army with live ammo and grenades are no more resopnsible than 18 year old in college. They do stupid things. And they get up the shit creek without paddle. On regular basis. Occasionaly, somebody gets hurt or even killed. Army is not as organized as it may seem on the surface. And once you send those 18 years old to some far away country, and they blow up a bus full of high school kids, nobody cares back home. And they don't get up shit creek without paddle. After all they were fighting for their country. There are reasons army prefers 18 years old over 38 years old. And responsibility is not one of them. Frankly, if the army could get away with recruiting 16 or 14 years old kids, they would do it.
The idea is that 18-years old is stupid enough to make a choice of getting killed. Period. No additional patriotic bullshit. And even more stupid to make a choice of killing other people ("for his country", as you said).
Come on people. Linus told long ago it chosed Larry's tool because there was nothing in open source world that was nearly as good. And 2.6 kernel and the speed it was being developed is more than enough proof of that.
On the other side, Larry made a deal. And he made a really good deal. Too bad it wasn't enforcable (both for him and Linus). I'll give you the best tool that exists on the planet for free, and in exchange you are not going to reverse engineer the protocol it uses. You can develop competing tool with its own protocol, though. This sounds like a good deal for open source comunity too. If anybody cares what I think about it. Open source comunity got a freebie.
So, while there is nothing unethical about reverse engineering the protocol, it is unethical not to keep the word you gave. If Larry struck the deal with real organization ("organizatoin" in legal sense of the word, as in legal entity), he could as well go to court and win. Easily. Luckily, it is virtually impossible to sue "open source comunity". Who exactly are you going to sue?
If anybody wants to hear my opinion, it was more than clear that somebody is going to backstab Linus and do exactly what Tridgel did. Come on people, Tridgel knew exactly what he was doing. Deal between Linus and Larry wasn't a big secret. It was spelled in big words: you may use it for free as long as nobody attempts to reverse engineer the protocol.
Deals are deals. When somebody breaks it, there is no deal anymore. It is that simple. You may be religious about the issues involved. You may be emotional. Or you may be cool headed. Whatever way you choose to react, you can't change simple facts.
Crap. They started adding HTML into email.
And for those saying that adding HTML does not waste bandwith, just consider this. I've created one-liner "Let's test bold stuff", with only single word "bold" in bold on GMail. Sent it. It created multipart/alternative email. First part was plain text. Second part was HTML. HTML part was 2.48 times in size of text part! Nice. And no, Google's idea of specifying something is bold is not good old "b" tag. They are fancier than that.
Counting the headers and everything else, the resulting multipart/alternative email was 30% larger than it would be if it was text-only. 30% larger, just to have single word bold in one-liner email! For larger emails where header/content ratio is lower, this would get even worse (closer to 100%, and for a bit longer texts such as this one probably well over double in size).
Now, one might say "who cares, I have 2GB for email". Well, news for you, I have 150GB (would have 300GB if it wasn't for the RAID1). I want to use that 150GB to be able to keep more email for longer time (which is basically idea behind GMail). Me, and everybody else who shares that 150GB of disk space with me. Not to store less email for shorter period of time.
And yes, vast majority of people will overdo things when you give them control over fonts, and will make texts look way worse than if they were simply plain text. The truth is, if something looks like it should be in bold, most likely it doesn't need to be. And if anybody cares to check typesetting hints and tips for making readable text, they say: use one font and stick with it in entire document, use special stuff (bold, italics) rarely and wisely.
Check your local newspapers, or grab any book from your bookshelf, and you'll see what I'm talking about. Than compare it to average HTML email. And see the difference.
BTW, would somebody explain to me why is specifying numbered list in HTML more readable then:
1. foo
2. bar
3. foobar
in plaintext?
Or why are bullets more readable than:
- one
- two
- three
Somehow I fail to see the difference.
Well, enough complaining. Time to finally modify my mimedefang-milter to drop all text/html parts. I need only one copy of what somebody wrote. Not two. Considering that more and more people are using GMail for mailing lists, my private mailing list archives are going to literary explode. Wish there was a way to prevent wasting my bandwith in the first place.
There's no way around it. Apperently there is a system call in Windows that application can use to request a memory page not to be swapped out, however it doesn't guarantee that the page will not be swapped out (unlike Unix memory lock, that actually locks the page into the memory). For more details, check discussions about it in GnuPG documentation/archives. Even if there was a way to prevent a memory page (containing your password) to be locked into the memory this way, obviously it would be application's responsibility to use it. I'm not aware of any web browser on Unix that actually use memory locking for memory pages that contain passwords (if there were, they would need to be setuid root in order to use the feature, which might be even worse scenario).
I don't know of any easy way of encrypting Windows swap file. The only system I used that has out of box, easy to use encryption of swap was OpenBSD (and probably other similar *BSD variants).
Overwriting swap file with zeros on reboots isn't going to save you either. Depending on how determined and resourcefull attacker is, information from "overwritten" disk blocks can be more or less easily retrieved (probably almost any university has equipment needed for that handy, and apperently it isn't that expensive either nowdays). Overwriting with several "special" patterns might help, but if NSA doesn't trust that method, why should you.
It is the system that makes ID theft possible. The system is made to be too transparent to the consumer instead of secure. Back in my home country, no bank would open and account or perform any other action or give out information simply because the person requesting it can answer couple of trivial questions such as date of birth and/or approximate account balance and with no ID checks at all. And that was long before ID theft become so big problem here in North America.
Does this cripples things such as telephone banking? Sure it does, if for anything non-trivial you need to show in person at counter with government issued photo-ID. But at least your money isn't going to end up in Nigeria overnight.
I was shoked after I moved to North America and found out that I can get credit card by simply making a phone call and simply telling the service representative on the other side my date of birth and answers to couple of other trivialities... Shees. Wake up folks. The system that is currently in place is a paradise for criminals.
Yes, you can use rlimit to limit some things. However, some limits are not completely implemented in Linux. For example, there is no way to effectively limit the number of virtual pages resident in RAM for a single process. The setrlimit for RLIMIT_RSS will only affect portions of memory where madvise was applied with MADVISE_WILLNEED (as per setrlimit manual page you mentioned).
I so totally do not agree with what you wrote. The operating system should protect itself and other processes from a single process going mad. If you don't have that as integral part of the OS, than why botter developing new stuff? We could all stayed with MS-DOS and Windows 3.11. Remember what was the most common objection to that combo? Single application goes bad, and entire system goes down. Same thing with fork bombs or any other implementation of "let make machine really busy doing something stupid, so that everything else on the system is brought to the halt". OS that dosn't have this kind of protections in place is, sorry but, really no better than DOS/Win3.11 combo.
Kernel efficiently protecting it's memory space is trivial to implement. It just uses something that already exists in hardware. Kernel that does more than that, well obviously it takes a bit more work...
Create huge sparse file (say 1 gig). mmap it into the memory. memset on 1 gig region. You don't even have to do it in a loop. Makes a big trouble if you have 256 or less RAM. And you don't need a loop either. If you do madvise prior to memset on that region with carefully selected advise value, all you can do is turn off the machine (or wait for a quite a long time for machine to recover). Now put that into loop ;-)
There's more ways to kill Linux box from user space. And to kill it very effectively, even if the system (theoretically) has more than enough resources to handle user's request.
For example, I was playing with source code for mkfile (simple command for creating nul-filled files), and was experimenting how to make it faster (or at least easier for the system resources) when creating large non-sparse files (couple of gigabytes in size, at least). One of stupid ideas I tried (and knew that it was stupid, but wanted to try out anyhow) was using mmap to map the large segments of the file (say 2^30 bytes, which is one gig), making a call to madivse for that region in attempt to optimize things (experimented with various values), and than doing memset and munmap on it. Run it to create 10 gig file. Guess what. Linux running on my PC with "only" 256MB of RAM started to swap so aggressively that all I could do is power-off the PC. I couldn't swith out of X to text console. SSH session from another machine was totaly dead. The machine was totaly dead, completely frozen. Except the disk light that was on. Single process that needs to swap a lot. And machine is *totally* dead.
Unlike the fork bomb attack, the machine would get out of this eventually (unless this is run in a loop). Probably in couple of hours. Or by the next day. I hadn't that much time on my hands, so I powered it off, and on again. Back to the drawing table.
I knew that what I coded wasn't smart, but to trash machine like that....
Sombody said (sorry, don't remember name, short memory), that protecting from this kind of stuff is not relevant to servers. I don't agree. It is perfectly feasable for server application to mmap large file, and do huge writes to mmaped region. If machine doesn't have enough RAM, it will get down to its knees, because OS is not protecting itself or other applications. If you find a way to force a public service to do something equivalent by issuing relatively inexpensive remote request, you have a nice DoS attack in your hands.
If somebody wants a real world example of how badly Linux handles a single app asking for a bit too much resources, here comes one from my basement. There's one old machine I use as web server, proxy server and cyrus imapd. It is an old machine, Pentium MMX, 96 megs RAM. For two user accounts, it works perfectly, and more than fast enough. Run "yum update", and things simply fall apart. It becomes completely unresponsive. Reason? Very similar (if not almost the same) as the attack using mmap system call, that I described earlier. Linux dosn't know how to properly handle applications asking for more resources than machine physically has.
I kind of agree with you. If person/organization requesting patent is unable to provide documentation that it invested considerable amount of time and resources in development, it shouldn't be granted a patent. Period. Patents shouldn't be lottery tickets (as they are today, sadly). They are supposed to give incentive for serious (and costly) development efforts. The way they are granted today (especially software patents) is a joke.