You are obviously not a programmer. Or at best, a novice one.
Buffer overflows are only one small class of exploit.
The latest xmlrpc attacks going around have absolutely nothing to do with buffer overflows; the fact they are even possible at all is due precisely to xmlrpc being "higher level language" than C.
In fact virtually no php attack is a buffer overflow. They are mostly script injection attacks enabled solely because php is such a high level language.
SQL/script injection attacks also have nothing to do with buffer overflows. In fact they are enabled precisely because they are high level languages.
To get a "completely stable, secure system" you'll have to give up far more than 5%. Try 50%-60%.
No, we're obsessed with cracking OS X so we can run it on actually decent hardware, instead of the overpriced underpowered piece of shit hardware with fruity logo on it that apple inflicts on everyone.
backend stuff doesnt have the interactive response issues that you have with a gui. you could use a language 10,000x slower than C and still be completely database bound in execution time, and still have little to no measurable difference in overall execution time between C, perl, php, java, or anything else.
4) the "flagship" applications so frequently touted as "proof of java success": eclipse and azureus. they are so bloated and slow that most people run away screaming. why people tout these as examples is beyond me. 5) is what is driving a lot of people to C#. that and the fact that C# took a more pragmatic approach to language problems, while java takes an idealistic one in the name of intellectual and academic purity. a lot of us wish the steering group would come down from their ivory tower and see whats going on at ground level.
modern catholicism is remarkably secular, catholics tend to be strong advocates for church-state separation. if a catholic school taught ID it was probably be to critique it.
catholic schools in general are very good at churning out hardened atheists (george carlin is one well known example). it would be ironic if catholic schools in kansas may turn out to be the last hiding place for a secular education.
lua is usually the first choice for an embedded scripting language, because it's so minimal. it's reasonably powerful and easy to sandbox. it would be very suprising if lua wasn't included.
the same way linux implemented the posix ABI (errno.h et al) without violating copyright. unless you're saying you actually support SCO's position that linux stole it.
linus already cleared the nvidia drivers as a derived work, retard.
The GPL cannot circumvent existing law -- no license can do that. (if licenses could actually do that, then you could eg write a license which subjected the customer to indentured servitude, first born child, etc. all highly illegal.)
The case for GPL violations of binary-only modules linking into the kernel is not so clear-cut. A binary-only module in that case violates if it is a derived work of Linux. And in the case of ATI and nvidia (and probably most other commercial binary-only drivers) they are not derived works -- they are (win32|solaris|etc) binary targets with a thin layer of linux glue. Linus made it quite clear they don't violate.
I fail to see how binary drivers would violate copyright. You aren't copying anything. License violation yes. Copyright violation no. Hence not illegal, contrary to the wild-eyed raving of TFA.
with a 'stable binary interface' it makes it much simpler to intercept the driver with a shim (this is why it's so trivial to RE win32 drivers for example. standardized ABI tends to do that.)
then when they're all feeling safe and secure, reverse engineer the rug out from underneath them, facilitated via the interface they lobbied for.
If they want to protect their IP they should patent it. secrecy gives them NO (capital N capital O, emphasized many times) protection. Anyone can reverse engineer their stuff and make a 100% legal clone unless it is patented.
And if it's patented, there's no point in hiding the source.
So really, what they are doing is incredibly risky.
Yes, you got that right, OSDL Japan wants a stable kernel api layer so they can write binary only kernel drivers, which are just so illegal it's not even funny.
How are binary only kernel drivers illegal? There isn't any law against binary only kernel drivers. The "L" in "GPL" means license, not law.
An element's chemical properties are intrinsically tied up in its electron shell
and
Deuterium is an isotope of hydrogen with an atomic mass of 2 instead of 1. It has noticeably different chemical properties to hydrogen
one might be able to explain the differences between D2O and H2O via thermodynamics, but it can't be explained via electron shell differences as the parent poster was alluding to. follow parent poster's reasoning on deuterium, and you would conclude that lithium's chemical reactivity with water is purely due to its neutrons.
What does a hydrino look like? How does it behave? An element's chemical properties are intrinsically tied up in its electron shell; and a hydrino has an electron shell that's significantly different from a conventional hydrogen atom. So, what chemical properties does a hydrino gas have?
This sort of thing is quite important. Deuterium is an isotope of hydrogen with an atomic mass of 2 instead of 1. It has noticeably different chemical properties to hydrogen, to such an extent that heavy water (water made with deuterium instead of hydrogen) is considered toxic.
Atomic mass comes from the nucleus, not the electrons. The number of electrons in deuterium and hydrogen is exactly the same. Moreover, the chemical properties of H2O and D2O are exactly the same. Deuterium is slightly toxic for altogether different reasons than chemical properties.
Slashdot Mirror
You are obviously not a programmer. Or at best, a novice one.
Buffer overflows are only one small class of exploit.
The latest xmlrpc attacks going around have absolutely nothing to do with buffer overflows; the fact they are even possible at all is due precisely to xmlrpc being "higher level language" than C.
In fact virtually no php attack is a buffer overflow. They are mostly script injection attacks enabled solely because php is such a high level language.
SQL/script injection attacks also have nothing to do with buffer overflows. In fact they are enabled precisely because they are high level languages.
To get a "completely stable, secure system" you'll have to give up far more than 5%. Try 50%-60%.
Do you blame GCC/VC++ as well? Most exploited software these days are C applications.
:P
Sure PHP could do better, but it's not unusual in this regard. It's just as mediocre as anything else.
The goals of grsecurity (mostly PAX) and SELinux are completely different.
SELinux is mainly a sandbox to restrict the damage a compromised application can inflict on a system.
grsecurity aims to prevent the compromise from happening in the first place.
They do seem to occur with increasing frequency these days.
I think that there will be an embedded Linux kernel running on a chip on the motherboard.
Nifty. I'll love to see the complete source code for this, which apple will be obligated to provide.
you're an apple fanboy because you assumed by default the only reason anyone wants to run OSX on generic hardware is to avoid paying for it.
So they don't have to pay for OS X?
No, we're obsessed with cracking OS X so we can run it on actually decent hardware, instead of the overpriced underpowered piece of shit hardware with fruity logo on it that apple inflicts on everyone.
backend stuff doesnt have the interactive response issues that you have with a gui. you could use a language 10,000x slower than C and still be completely database bound in execution time, and still have little to no measurable difference in overall execution time between C, perl, php, java, or anything else.
implementing a UI in opengl is actually the best way to maintain portability across platforms :-/ short of using Qt or something like that.
being suprised that lua is listed, but not being suprised that ecmascript is listed... that is what I find odd.
4) the "flagship" applications so frequently touted as "proof of java success": eclipse and azureus. they are so bloated and slow that most people run away screaming. why people tout these as examples is beyond me.
5) is what is driving a lot of people to C#. that and the fact that C# took a more pragmatic approach to language problems, while java takes an idealistic one in the name of intellectual and academic purity. a lot of us wish the steering group would come down from their ivory tower and see whats going on at ground level.
modern catholicism is remarkably secular, catholics tend to be strong advocates for church-state separation. if a catholic school taught ID it was probably be to critique it.
catholic schools in general are very good at churning out hardened atheists (george carlin is one well known example). it would be ironic if catholic schools in kansas may turn out to be the last hiding place for a secular education.
it's a pity java is so slow though, at least the gui apps are.
the "flagship" examples of "successful gui java apps" like azureus and eclipse are monstrously slow and bloated, and complaints about them are common.
all the third party java apps our business partner uses and all the ones they've developed from scratch are slow too.
java might be nice for portability and even server backend stuff, but java still has a long, long ways to go on gui performance.
there are also enough issues with major JVM incompatibilities across platforms that the current joke for java is "write once, run nowhere".
lua is usually the first choice for an embedded scripting language, because it's so minimal. it's reasonably powerful and easy to sandbox. it would be very suprising if lua wasn't included.
the same way linux implemented the posix ABI (errno.h et al) without violating copyright. unless you're saying you actually support SCO's position that linux stole it.
linus already cleared the nvidia drivers as a derived work, retard.
The GPL cannot circumvent existing law -- no license can do that. (if licenses could actually do that, then you could eg write a license which subjected the customer to indentured servitude, first born child, etc. all highly illegal.)
The case for GPL violations of binary-only modules linking into the kernel is not so clear-cut. A binary-only module in that case violates if it is a derived work of Linux. And in the case of ATI and nvidia (and probably most other commercial binary-only drivers) they are not derived works -- they are (win32|solaris|etc) binary targets with a thin layer of linux glue. Linus made it quite clear they don't violate.
I fail to see how binary drivers would violate copyright. You aren't copying anything. License violation yes. Copyright violation no. Hence not illegal, contrary to the wild-eyed raving of TFA.
help them delude themselves? sure, why not.
with a 'stable binary interface' it makes it much simpler to intercept the driver with a shim (this is why it's so trivial to RE win32 drivers for example. standardized ABI tends to do that.)
then when they're all feeling safe and secure, reverse engineer the rug out from underneath them, facilitated via the interface they lobbied for.
make their lives easier, and ours too.
If they want to protect their IP they should patent it. secrecy gives them NO (capital N capital O, emphasized many times) protection. Anyone can reverse engineer their stuff and make a 100% legal clone unless it is patented.
And if it's patented, there's no point in hiding the source.
So really, what they are doing is incredibly risky.
Yes, you got that right, OSDL Japan wants a stable kernel api layer so they can write binary only kernel drivers, which are just so illegal it's not even funny.
How are binary only kernel drivers illegal? There isn't any law against binary only kernel drivers. The "L" in "GPL" means license, not law.
What problem are they trying to solve... ...lack of vendor lock-in?
webster's also defines isotopes as having the exact same chemical properties.
if you care to redefine the dictionary, go for it.
i can play pedant just as well as you can. you seem to enjoy it though, so knock yourself out.
chemically the same @ wikipedia
the NRC also describes tritium as chemically identical. the iaea describes isotopes as "chemically identical but physically different".
maybe you should argue with them? i trust the iaea more than mr. random slashdotter aka you.
parent poster stated:
An element's chemical properties are intrinsically tied up in its electron shell
and
Deuterium is an isotope of hydrogen with an atomic mass of 2 instead of 1. It has noticeably different chemical properties to hydrogen
one might be able to explain the differences between D2O and H2O via thermodynamics, but it can't be explained via electron shell differences as the parent poster was alluding to. follow parent poster's reasoning on deuterium, and you would conclude that lithium's chemical reactivity with water is purely due to its neutrons.
What does a hydrino look like? How does it behave? An element's chemical properties are intrinsically tied up in its electron shell; and a hydrino has an electron shell that's significantly different from a conventional hydrogen atom. So, what chemical properties does a hydrino gas have?
This sort of thing is quite important. Deuterium is an isotope of hydrogen with an atomic mass of 2 instead of 1. It has noticeably different chemical properties to hydrogen, to such an extent that heavy water (water made with deuterium instead of hydrogen) is considered toxic.
Atomic mass comes from the nucleus, not the electrons. The number of electrons in deuterium and hydrogen is exactly the same. Moreover, the chemical properties of H2O and D2O are exactly the same. Deuterium is slightly toxic for altogether different reasons than chemical properties.