Well over here the process also reduces the odds of people having more than their approved number of spouses.
Apparently the plural of spouse isn't spice;).
Re:The problems of code injection
on
Gosling on Computing
·
· Score: 2, Interesting
But it's quite different if a programmer intentionally executes a user supplied arbitrary string without filtering it. Not the same as a programmer makes a low-level mistake (off by one, not having the numbers right) and then user supplied arbitrary code is executed.
The first is a "not thinking straight" problem and requires stupidity/ignorance which is common. The second is a "typo class" problem and only requires imperfection which is nearly ubiquitous -even smart and knowlegeable people make such mistakes (some even do it regularly).
As for other languages: I crashed a forth webserver the first time I tried:). I used a ' as password when it prompted for username and password for an access controlled URL. Turns out ' is a special forth keyword so Boom!
As the author of the webserver said when I emailed him: "the line between CODE and DATA is blurred by Lisp and obliterated by Forth.:)"
That's dangerous if you don't know what you're doing...
At least with perl if you turn on tainting and "use strict" a lot of exploits become very difficult. Whereas with C you need to keep remembering to do the right thing. Global "make things safer" switches are good for most people.
If you ALWAYS use SQL prepared statements in Java, in one sweep you make SQL injection attacks a lot harder. After that you need to make sure that LIKE queries don't have unwanted wildcards, and that stuff like a=b-parameter is either a=b - parameter or a=b-(parameter) so that if parameter is a negative number it doesn't create an SQL comment.
Then either you turn off multibyte/multilingual support or hope that the database implements it correctly. There was a bug in a database where a particular invalid multibyte word caused the following character to be "eaten" up. Imagine if the following character was a ' or \. The DB developer who mentioned the prob didn't even realize the severity of that prob and I had to give examples. Eye-opener...
It's dangerous to use a programming language where common programmer mistakes allow "remote attackers to execute arbitrary code of their choice with the process's privileges".
Once they do that we'll only have to worry about stuff like SQL injection (which can result in execution of arbitrary code), which can be reduced/near eliminated by making people use prepared statements.
In some cases it'll still be necessary to use the unsafe languages, but nearly 100% of the programmers in the world obviously can't code safely in C or similarly vulnerable languages.
Even Eric Allman couldn't (see Sendmail for evidence).
Because when you want to buy 100+ PCs or servers most IT people don't want to hand build all of them. They just want to buy them from someone who builds, tests, delivers and deals with the faulty ones.
Only recently have HP, IBM, Sun started making AMD boxes. And only recently has one of them started _pushing_ them. There's a difference between saying "available" and saying "buy this it's good".
And it doesn't help that Dell has been cheaper than HP/IBM/Sun in the "cheap end". As many people point out you don't need 3GHz, so if you buy the 2nd cheapest Dell, you've got pretty good bang for the buck.
It'll be interesting if Dell starts selling opteron servers. But what are the odds?
I'm not sure what you mean with your first two sentences. The first line of my post was a quote of the AC.
Any programming language where it is _common_ for a small mistake (e.g. off by one) to "allow an attacker to remotely execute arbitrary code of his/her own choice" should be avoided where possible.
So if it's common for that to happen to C++ then avoid it as well. Or start changing things (e.g. default behaviours, libraries, methods etc) so that it's uncommon.
Stick to a solid foundation and people will be able to spend more time building a lot more without having to waste time patching/updating each layer every two weeks.
With regards to OSes, it's kind of a step backwards that an O/S should ever have to "panic" for silly little stuff like having trouble with peripheral hardware.
The amount of competence required to write safe programs in C is beyond most people - smart people can be stupid and ignorant too sometimes.
Not all programs need to be safe - e.g. stuff which only takes input from trusted sources. But the requirement for safety and reliability is spreading.
See cpan.org for large bodies of code that appears to be maintained. And even better - it's actually reused by many thousands of people.
The geniuses/great hackers do the hard work and write tons of modules to deal with almost any situation the stupid coders like me would need. And the great hackers actually write the modules for _usage_, not to fulfill some PHB's or Market Droid's requirement.
As long as the stupid ones are lazy and use the modules done by the great hackers, they write less code, and thus there is a smaller mess to deal with.
Code reuse? Check. Maintainable code? Check.
With Java the stupid and lazy typically HAVE to write more code. Have to write their own code to do common stuff like get the number of rows returned by the last SQL query, etc etc. WTF.
If you don't mind HALF your processing being wasted, just get a scheduler that _never_ allows a single process/thread to use more than 50% of CPU. Next reduce your time slices to something higher than 100Hz. Given multi GHz CPUs, even switching every 2KHz may not be a problem.
Then it'll behave very like a dual SMP machine with 2 CPUs at half speed.
That said, I wonder if SMP machines still lock up and wait for the CDROM drive for Windows machines?
"A competent C programmer knows how to avoid buffer overflows."
"knowing" and "doing" are very different things.
So far it seems like that there are fewer than 5 people in the world who can do it successfully in contrast to the millions who merely _think_ they can.
Just take a look at the bugtraq mailing list. apache, ssh, openssl, linux kernel, etc. So do those developers know how to avoid buffer overflows?
Nowadays using C when it isn't absolutely necessary is being stupid or ignorant.
The easiest way to avoid buffer overflows is to use a sane programming language. Any programming language where it is _common_ for a small mistake (e.g. off by one) to "allow an attacker to remotely execute arbitrary code of his/her own choice" should be avoided where possible.
Open source isn't necessarily better than closed source, especially when it comes to security problems. PHPNuke Sendmail, BIND, [insert other poor track record OSS here] have been open source for years.
It's a matter of who is writing the programs (and often _why_), not whether it's open source or closed source.
Many eyes do NOT find security bugs. It takes _experienced/skilled_ eyes to find them.
The fallacy of saying many eyes make bugs shallow is like saying a billion monkeys will write Shakespeare (the works not the name). There aren't enough monkeys, so you need quality and not quantity for such things.
The average joe doesn't even _see_ the error message that flashes in front of him before he clicks OK/Cancel to dismiss it. Many even deny clicking OK or Cancel too. Billions of average joe eyes are useless for finding security bugs. They're useful for finding UI usage bugs (doh).
Heck, my excolleague has done similar things years ago too.
He played a prank on another colleague that involved making the desktop background a centered image of a windows error message - one of those serious looking "illegal exception" things if I recall correctly.
Naturally when the victim clicks on the OK or Cancel it doesn't work. Then the victim actually got rather worried...
My colleague got pretty worried when I installed the bluescreen screen saver on his PC as an april fool's joke.
I dunno about you but I sometimes find myself clicking the OK/Cancel buttons on example images on some websites. This even tho I set my personal colour scheme different from the normal windows standard (to intentionally help combat this problem).
Rewriting old C software into POSIX C seems even more pointless. Coz if he rewrites it, wouldn't they still have the same problem 10 years later?
If they really want to rewrite the software why do it in C of all languages? Why not python or java or even perl? At least you won't have to worry about stupid buffer overflow errors and crap like that.
Python, Java and Perl run on quite a number of platforms the last I checked. java would run fairly fast (given enough memory...).
Since the existing stuff works and there's no urgent need to shift, you can take time to build the "blueprint" program, then the "plastic model" program, and then the actual program. That way you should really get something with quality[1].
[1]The trouble with most software is you are usually sold/given the "blueprint" just because the blueprint actually compiles (probably with thousands of warnings) and "works". If you're lucky you're sold the "Plastic model".
The other problem is unlike civil engineering etc, the blueprint and plastic models each cost about the same to make as the real thing. So it is rare you get to go through all the steps and just sell the real thing as your first product.
Translation of translation: The demand for the new Prescott P4s is a bit lower than "expected". Coz it's significantly hotter, and not really faster than the old chips. And it isn't really cheaper. A fair number of people are going for Northwoods instead of Prescotts. And a significant number are actually going AMD.
It's about changing the hydrophobic/hydrophilic (water repellent/attractive) properties of a _special_ surface using light. This doesn't work on just any surface.
I dare say the military would prefer to dehydrate parts of your body by vapourizing bits of it e.g. zap you directly with a powerful beam of light. Or ionizing air between a thundercloud and you so that a lightning bolt zaps you ( that's to make it look like an "Act of God").
The thing about a pulse is the blood vessel valves need only open at the peak pressure of the pulse. The rest of the time the blood pressure can be quite low. On average the blood will still flow the right way.
Whereas for a pulseless heart the blood pressure has to be at the peak continuously. There are also other issues to do with general plumbing - I read somewhere that heart surgeons have found putting a slight twist in a bypass vein makes it less likely to clog up. Theory is that it causes the blood to swirl and that could help keep the vessels clear and healthy. I can't find the original article (New Scientist) but you can read about it here.
Quote: "They discovered that the smooth shear stress caused three genes to become more active (New Scientist, Science, 5 October 1996, p 17). Two of these code for enzymes that reduce blood clotting and protect cells from damage. The third gene produces a protein vital for the synthesis of nitric oxide, which inhibits the development of thrombi--blood clots--and prevents the surrounding layer of smooth muscle cells from overgrowing the endothelial layer. But the activities of these genes were barely detectable in cells that felt turbulent shear stress or no stress at all. Some stress, it seems, is a good thing. "
So without a pulse it is likely that the cells may not behave correctly.
Well at least you might have some fun with the old-style lie detector tests:).
Not sure what you mean "by base system requirements that will make the investment worthwhile".
If you want it _now_ and it fits the budget get an Athlon64 3000+. AMD recently _raised_ the price of the 2800+. The 3200+ is ok - there are two versions of the 3200+ tho.
Yeah. Maybe they should bribe the Palestinians with billions of dollars to go live elsewhere or something.
Rumsfield says the US spends about USD4 billion (3.9) on Iraq a month. 12 months = 36 billion. Spread over 9 million palestinians that's USD4000 per person (man, woman, child). For a family of 4 that's not bad household income actually. Most are probably fed up enough to leave - it's just they have no where to go - let them live in Montana or something.
That's not including reconstruction costs. The US also spends USD1 billion on Afghanistan a month.
Sure, some will still go bomb stuff/people, but y'know when your stomach is full, your family is happy and you're enjoying playing with the other kids and stuff, the motivation to strap on a bomb and actually blow yourself up has got be a lot lower. May still spout words of hate, but when it comes down to pushing the button, would you? Give them something to lose and they won't want to lose it.
Right now, they can't work, they can't travel, can barely live, their friends and leaders are saying hate the Israelis, the Israelis are giving them lots of opportunities to justify the hatred.
But tanks, guns and soldiers are probably more effective eh? (Personally I think it's as effective as giving a half dose of antibiotics to bacteria.)
Call me cynical but maybe that's part of the plan - it's all part of setting the stage for something else later on.
Slashdot Mirror
That's what I call code reuse. :)
Yeah it still works in places where there's no access to the internet and someone didn't conveniently mirror the relevant portions for you.
Well over here the process also reduces the odds of people having more than their approved number of spouses.
;).
Apparently the plural of spouse isn't spice
But it's quite different if a programmer intentionally executes a user supplied arbitrary string without filtering it. Not the same as a programmer makes a low-level mistake (off by one, not having the numbers right) and then user supplied arbitrary code is executed.
:). I used a ' as password when it prompted for username and password for an access controlled URL. Turns out ' is a special forth keyword so Boom!
:)"
The first is a "not thinking straight" problem and requires stupidity/ignorance which is common. The second is a "typo class" problem and only requires imperfection which is nearly ubiquitous -even smart and knowlegeable people make such mistakes (some even do it regularly).
As for other languages: I crashed a forth webserver the first time I tried
As the author of the webserver said when I emailed him: "the line between CODE and DATA is blurred by Lisp and obliterated by Forth.
That's dangerous if you don't know what you're doing...
At least with perl if you turn on tainting and "use strict" a lot of exploits become very difficult. Whereas with C you need to keep remembering to do the right thing. Global "make things safer" switches are good for most people.
If you ALWAYS use SQL prepared statements in Java, in one sweep you make SQL injection attacks a lot harder. After that you need to make sure that LIKE queries don't have unwanted wildcards, and that stuff like a=b-parameter is either a=b - parameter or a=b-(parameter) so that if parameter is a negative number it doesn't create an SQL comment.
Then either you turn off multibyte/multilingual support or hope that the database implements it correctly. There was a bug in a database where a particular invalid multibyte word caused the following character to be "eaten" up. Imagine if the following character was a ' or \. The DB developer who mentioned the prob didn't even realize the severity of that prob and I had to give examples. Eye-opener...
It's dangerous to use a programming language where common programmer mistakes allow "remote attackers to execute arbitrary code of their choice with the process's privileges".
Once they do that we'll only have to worry about stuff like SQL injection (which can result in execution of arbitrary code), which can be reduced/near eliminated by making people use prepared statements.
In some cases it'll still be necessary to use the unsafe languages, but nearly 100% of the programmers in the world obviously can't code safely in C or similarly vulnerable languages.
Even Eric Allman couldn't (see Sendmail for evidence).
Because when you want to buy 100+ PCs or servers most IT people don't want to hand build all of them. They just want to buy them from someone who builds, tests, delivers and deals with the faulty ones.
Only recently have HP, IBM, Sun started making AMD boxes. And only recently has one of them started _pushing_ them. There's a difference between saying "available" and saying "buy this it's good".
And it doesn't help that Dell has been cheaper than HP/IBM/Sun in the "cheap end". As many people point out you don't need 3GHz, so if you buy the 2nd cheapest Dell, you've got pretty good bang for the buck.
It'll be interesting if Dell starts selling opteron servers. But what are the odds?
Does that require shared disk?
And what if you have a VM with 2GB of ram - would that take 2GB/network bandwidth seconds to migrate to another machine?
They *can* change it to mean the same thing. I didn't say they did.
They still might. Given that so many people already believe it is theft.
Doesn't seem too hard looking at situation.
"Copyright Infringement does not equal Theft, and there is nothing that you can say or do to change that."
The law makers can change that...
I'm not sure what you mean with your first two sentences. The first line of my post was a quote of the AC.
Any programming language where it is _common_ for a small mistake (e.g. off by one) to "allow an attacker to remotely execute arbitrary code of his/her own choice" should be avoided where possible.
So if it's common for that to happen to C++ then avoid it as well. Or start changing things (e.g. default behaviours, libraries, methods etc) so that it's uncommon.
Stick to a solid foundation and people will be able to spend more time building a lot more without having to waste time patching/updating each layer every two weeks.
With regards to OSes, it's kind of a step backwards that an O/S should ever have to "panic" for silly little stuff like having trouble with peripheral hardware.
The amount of competence required to write safe programs in C is beyond most people - smart people can be stupid and ignorant too sometimes.
Not all programs need to be safe - e.g. stuff which only takes input from trusted sources. But the requirement for safety and reliability is spreading.
See cpan.org for large bodies of code that appears to be maintained. And even better - it's actually reused by many thousands of people.
The geniuses/great hackers do the hard work and write tons of modules to deal with almost any situation the stupid coders like me would need. And the great hackers actually write the modules for _usage_, not to fulfill some PHB's or Market Droid's requirement.
As long as the stupid ones are lazy and use the modules done by the great hackers, they write less code, and thus there is a smaller mess to deal with.
Code reuse? Check.
Maintainable code? Check.
With Java the stupid and lazy typically HAVE to write more code. Have to write their own code to do common stuff like get the number of rows returned by the last SQL query, etc etc. WTF.
So if things get really bad, maybe one should do the development elsewhere.
That's just a scheduler problem.
If you don't mind HALF your processing being wasted, just get a scheduler that _never_ allows a single process/thread to use more than 50% of CPU. Next reduce your time slices to something higher than 100Hz. Given multi GHz CPUs, even switching every 2KHz may not be a problem.
Then it'll behave very like a dual SMP machine with 2 CPUs at half speed.
That said, I wonder if SMP machines still lock up and wait for the CDROM drive for Windows machines?
"A competent C programmer knows how to avoid buffer overflows."
"knowing" and "doing" are very different things.
So far it seems like that there are fewer than 5 people in the world who can do it successfully in contrast to the millions who merely _think_ they can.
Just take a look at the bugtraq mailing list. apache, ssh, openssl, linux kernel, etc. So do those developers know how to avoid buffer overflows?
Nowadays using C when it isn't absolutely necessary is being stupid or ignorant.
The easiest way to avoid buffer overflows is to use a sane programming language. Any programming language where it is _common_ for a small mistake (e.g. off by one) to "allow an attacker to remotely execute arbitrary code of his/her own choice" should be avoided where possible.
Open source isn't necessarily better than closed source, especially when it comes to security problems. PHPNuke Sendmail, BIND, [insert other poor track record OSS here] have been open source for years.
It's a matter of who is writing the programs (and often _why_), not whether it's open source or closed source.
Many eyes do NOT find security bugs. It takes _experienced/skilled_ eyes to find them.
The fallacy of saying many eyes make bugs shallow is like saying a billion monkeys will write Shakespeare (the works not the name). There aren't enough monkeys, so you need quality and not quantity for such things.
The average joe doesn't even _see_ the error message that flashes in front of him before he clicks OK/Cancel to dismiss it. Many even deny clicking OK or Cancel too. Billions of average joe eyes are useless for finding security bugs. They're useful for finding UI usage bugs (doh).
Heck, my excolleague has done similar things years ago too.
He played a prank on another colleague that involved making the desktop background a centered image of a windows error message - one of those serious looking "illegal exception" things if I recall correctly.
Naturally when the victim clicks on the OK or Cancel it doesn't work. Then the victim actually got rather worried...
My colleague got pretty worried when I installed the bluescreen screen saver on his PC as an april fool's joke.
I dunno about you but I sometimes find myself clicking the OK/Cancel buttons on example images on some websites. This even tho I set my personal colour scheme different from the normal windows standard (to intentionally help combat this problem).
"Too bad most of the rest of the laptop-buying audience is too dense to look past the bling of clock speed numbers."
Uh. It's hard to look past the bling of not enough money.
The "Centrino" notebooks are significantly more expensive than the P4 ones.
Even if the specs aren't the same, it's hard to buy a Centrino notebook that's cheaper. They're generally marketed as a more expensive range.
Rewriting old C software into POSIX C seems even more pointless. Coz if he rewrites it, wouldn't they still have the same problem 10 years later?
If they really want to rewrite the software why do it in C of all languages? Why not python or java or even perl? At least you won't have to worry about stupid buffer overflow errors and crap like that.
Python, Java and Perl run on quite a number of platforms the last I checked. java would run fairly fast (given enough memory...).
Since the existing stuff works and there's no urgent need to shift, you can take time to build the "blueprint" program, then the "plastic model" program, and then the actual program. That way you should really get something with quality[1].
[1]The trouble with most software is you are usually sold/given the "blueprint" just because the blueprint actually compiles (probably with thousands of warnings) and "works". If you're lucky you're sold the "Plastic model".
The other problem is unlike civil engineering etc, the blueprint and plastic models each cost about the same to make as the real thing. So it is rare you get to go through all the steps and just sell the real thing as your first product.
Translation of translation: The demand for the new Prescott P4s is a bit lower than "expected". Coz it's significantly hotter, and not really faster than the old chips. And it isn't really cheaper. A fair number of people are going for Northwoods instead of Prescotts. And a significant number are actually going AMD.
Looks like you didn't RTFA.
It's about changing the hydrophobic/hydrophilic (water repellent/attractive) properties of a _special_ surface using light. This doesn't work on just any surface.
I dare say the military would prefer to dehydrate parts of your body by vapourizing bits of it e.g. zap you directly with a powerful beam of light. Or ionizing air between a thundercloud and you so that a lightning bolt zaps you ( that's to make it look like an "Act of God").
The thing about a pulse is the blood vessel valves need only open at the peak pressure of the pulse. The rest of the time the blood pressure can be quite low. On average the blood will still flow the right way.
:).
Whereas for a pulseless heart the blood pressure has to be at the peak continuously.
There are also other issues to do with general plumbing - I read somewhere that heart surgeons have found putting a slight twist in a bypass vein makes it less likely to clog up. Theory is that it causes the blood to swirl and that could help keep the vessels clear and healthy. I can't find the original article (New Scientist) but you can read about it here.
Quote: "They discovered that the smooth shear stress caused three genes to become more active (New Scientist, Science, 5 October 1996, p 17). Two of these code for enzymes that reduce blood clotting and protect cells from damage. The third gene produces a protein vital for the synthesis of nitric oxide, which inhibits the development of thrombi--blood clots--and prevents the surrounding layer of smooth muscle cells from overgrowing the endothelial layer. But the activities of these genes were barely detectable in cells that felt turbulent shear stress or no stress at all. Some stress, it seems, is a good thing. "
So without a pulse it is likely that the cells may not behave correctly.
Well at least you might have some fun with the old-style lie detector tests
Even if they do check you might end up with a wooden stake through your fancy pulseless heart tho.
apps: 3D games?
Not sure what you mean "by base system requirements that will make the investment worthwhile".
If you want it _now_ and it fits the budget get an Athlon64 3000+. AMD recently _raised_ the price of the 2800+. The 3200+ is ok - there are two versions of the 3200+ tho.
If you don't want it _now_. Just wait.
64 bit drivers and backward compatibility with "legacy" binaries?
Yeah. Maybe they should bribe the Palestinians with billions of dollars to go live elsewhere or something.
Rumsfield says the US spends about USD4 billion (3.9) on Iraq a month. 12 months = 36 billion. Spread over 9 million palestinians that's USD4000 per person (man, woman, child). For a family of 4 that's not bad household income actually. Most are probably fed up enough to leave - it's just they have no where to go - let them live in Montana or something.
That's not including reconstruction costs. The US also spends USD1 billion on Afghanistan a month.
Sure, some will still go bomb stuff/people, but y'know when your stomach is full, your family is happy and you're enjoying playing with the other kids and stuff, the motivation to strap on a bomb and actually blow yourself up has got be a lot lower. May still spout words of hate, but when it comes down to pushing the button, would you? Give them something to lose and they won't want to lose it.
Right now, they can't work, they can't travel, can barely live, their friends and leaders are saying hate the Israelis, the Israelis are giving them lots of opportunities to justify the hatred.
But tanks, guns and soldiers are probably more effective eh? (Personally I think it's as effective as giving a half dose of antibiotics to bacteria.)
Call me cynical but maybe that's part of the plan - it's all part of setting the stage for something else later on.