> The formal specification was just as rigorous and complex as a computer program. The program became little more than a different expression of the formal specifications
Have you got an example of this? The specification of what you want to do is generally significantly simpler than how you actually do something.
>Cuban medicine has shown for years that mother nature provides all kinds of wonderful molecules for free. They even have a
>bio-version of Viagra. Problem is these things are not patentable. So a large medicinal company has to spend tons of money on
>trials and FDA approval, and the very next day half a dozen competitors can throw a "me too" version on the market without
>incurring those costs. Sorry for you if you have cancer, but don't hold your breath 'cause it ain't gonna happen.
What you're saying simply isn't true. What Cuban medicine are you referring to by the way? I find it very hard to believe it isn't used in other countries if there is evidence it works.
This is from the blog of a neuroscientist, who typically replies to pseudoscientific claims from alternative medicine advocates, with regard to your grossly simplified claims about cancer medicine. Summary: you can patent modified unpatentable products, the university/government carries out this research all the time (as shown by the article you replied to!), unpatentable products can be marketed in most countries with no research needed.
http://www.theness.com/neurologicablog/default.asp?Display=101
"It is true that substances that can be obtained from nature without alteration cannot be patented you cannot patent a plant and that this reduces their profitability. But despite this, there are many studies into herbs and other widely used unpatentable products. Such studies are carried out by university based or government funded research...Further, regulations in the US and most other countries are such that unpatentable products can be marketed without requiring pre-market research. This is a huge advantage in the marketplace. The proof of the pudding is in the tasting the supplement industry has exploded to a multi-billion dollar industry. Also, there is no longer a distinction between the pharmaceutical industry and the supplement industry, and big pharma has learned there is money to be made in supplements. So it is not plausible to cry boo hoo about the poor oppressed natural product industry, when they are doing just fine, making billions, and even tempting the pharmaceutical industry to get in on the action. "
http://www.theness.com/neurologicablog/default.asp?Display=28
"Yesterday Jeff asked, I just read a story about a new drug that apparently cures most types of cancers. The problem is that it is not patented so no drug company will pay for the trials. It just sounds too good to be true. Here is the link.... The bottom line is that if the science is solid and the potential very promising, the research will likely get done. Careers can be made from such research, universities could fund cancer centers and raise their prestige and profile, and there could also be a great deal of money to be made from such a treatment (even if it is not as much as from a patentable drug).
There persists a nonsensical and very cynical myth that the medical establishment or the pharmaceutical industry already has a cure for cancer, but are suppressing it in order to protect their profits from treating (rather than curing) cancer. This episode shows, in my opinion, how silly that myth is. Researchers are doing university-based research to show the potential of a substance that cannot be patented as a cancer treatment. The research has been published and so is available to the public, and the media are spreading the word far and wide. No conspiracy has prevented this research from happening or knowledge of it from spreading."
> Any sort of technology is available for fraud, but this is 100x better > then the signature security as well as the PIN is not transmitted past > the terminal because it is all handled through the card. Basically the > CHIP on the card is asked if the entered PIN is valid and the chip is > responsible for authorizing it, not some remote system that needs to be > verified with.
When a shop asks you to use chip in pin, you insert your card into a black box with numbers on it. You have no idea what this black box does. When you insert your card and type in your pin, it might only verify your transaction. Another thing it could do is scan and save the magnetic strip on your card and record your pin number. You would be none the wiser. Somebody could then create a copy of your card (minus chip) and then use it to withdraw cash from a cashpoint (possibly in another country).
How do you know if the machine handed to you won't do this? You can't; it's a fatally flawed system. It's similar to if a potential hacker asked you to use their keyboard to log into an account; there might be a hardware or a software keylogger running and you couldn't tell.
At least with a signature there is some way to prove that it wasn't you withdrawing the money and you don't go handing out your pin number to everyone. Your above description would sound good if the card actually contained the keypad, but the is provided by untrusted third parties.
"Some people actually work with.EXEs for a living. GMail is worthless to those people."
Don't you have a company email account for that? Gmail probably doesn't let you email 50+ people at a time to stop spammers abusing it. That would also fall under your "some people actually need to do this for a living" reasoning. The vast majority of people have no reason to email others.exe files, send mail to 50+ people at a time etc. so it makes sense to block these to prevent abuse.
Could anyone explain to me why backward compatability on a console is such a big deal? We didn't have it, for example, for the NES->SNES->Nintendo 64->Gamecube transitions and nobody really minded. If you already own XBOX games, you've already got a XBOX to play them on. I can't imagine many people want to buy old XBOX games for their brand new XBOX360 either. OK, some people might want to get the better known games (e.g. HALO) but it really isn't worth the hassle of backwards compatibility in my opinion. Isn't one of the advantages of consoles is that they have hardware that is more appropriate to pure gaming because they aren't constrained by ten years worth of old architecture (i.e. like the PC is)?
Exactly, there's nothing special about computer games that means they cannot be multi-threaded. It just so happens that all major game platforms have been single-threaded so far so programmers don't have much experience with it.
What the hell? Not a single XBox 360 programmer can work out how to create new threads and identify at least some processes that are not dependent one each other? That sounds like complete nonsense to me. There are plenty of easy ways to separate your level setup, game logic, sound processing, graphics, AI, physics etc. into different threads. I'm not saying taking full advantage of all cores is easy, but the idea that none of the game developers have the ability to use more than one thread is stupid.
One aspect that wasn't mentioned about Apple is vendor lock-in. In a couple of years, it is conceivable that some fantastic new type of MP3 device from another company will come out that lots of iPod users will want to switch to. When Joe the iPod user realises he has bought over $2000 worth of music from iTunes and he can't change to a non-Apple MP3 player because he can't play his music, he's going to be very annoyed. The majority of the population do not understand what DRM music and vendor lock-in means as they are merrily purchasing their MP3s from iTunes. This problem really needs to be addressed as Apple is selling the most downloaded music around and every track sold means they tighten their grip on the MP3 downloads/player market. Perhaps you could argue that they are leveraging their MP3 downloads market into the MP3 player market? Each product should be strong enough to compete on their own without this vendor lock-in to help as this hurts product quality and price for customers (they can't buy, say, cheaper DRMed MP3s from somewhere else because they can't play them and they can't switch music player because they can't play their current collection).
By the way, is there any need to write a one paragraph reply to every sentence from the OP? You should be able to articulate your position without having to do this; it's just excessive to take each sentence out of context and try to rip it to pieces. It looks like your trolling.
I always find it unfair when Linux distros are labelled poor because they don't support somebody's hardware, like their wireless card not working. The Linux developers would happily develop drivers for software if they were given the hardware specs to do so, but that isn't the case and drivers must be created with little help from the manufacturer. For example, I'm sure Novell would love to have native drivers for every wireless card out there, but if the companies won't co-operate, the best they can do is the ugly hack of using the win32 driver wrapped in an emulation layer. It's similar to complaining about why you can't play Playstation 2 games on Xbox hardware; the latter was never designed to work on the former and Microsoft wouldn't offer any help to get it working, but that doesn't mean Playstation 2 games are rubbish.
" I'll repeat what I've said before writing with a real string type in C, is not hard... and provides all the same benifits. The problem is convincing people that it can be fast enough (and even now, speed outweighs security for most customers)."
A C program which meets the C language specification can contain buffer overflows so it simply does not have the same benefits as languages that do not allow buffer overflows. It doesn't matter if you can spend a lot of time writing a very secure C string type; you can easily create exploitable, difficult to find buffer overflows in the rest of the C code you write. It is insane that not using a buffer properly can allow a third party to take control of your computer. Why is using a language that lets this happen acceptable for writing secure programs?
A type-safe C program can contain buffer overflows. A type-safe Java, ML, OCaml, Haskell, Python, Cyclone etc. program cannot. Buffer overflows constitute 90% of the security problems found in todays software. Blaming the programmer for buffer overflows doesn't make sense, especially when expert users have these bugs in their code. You shouldn't be writing secure programs in a programming language that is fundamentally insecure.
All you need is one exploitable buffer overflow bug in an internet based program on your computer and your computer could get hacked, get a virus, get spyware etc. Expecting every programmer in the world to be good enough to not create buffer overflow bugs is not a realistic or scalable approach to this security problem.
"Sure, it may be a good start to remove some of the bugs, but who writes the sandbox? In what language? Is the sandbox itself sandboxed, to prevent being comprimised? If so, who writes that sandbox? In what language? Is that sandbox itself sandboxed, to prevent being comprimised? If so... It's not an "obvious solution." It's an "obvious time-saver" when it comes to having to check for bugs."
To use Java as an example (I'm not advocating Java, just the idea), somebody writes a secure Java virtual machine once and everyone uses that as their platform. If a buffer overflow is found in the virtual machine (a single program), it is fixed once and all programs that use it are now more secure. The virtual machine code can also be heavily audited and over time it is unlikely to contain any easily exploitable security issues. With the current approach, buffer overflows need to be found and corrected in every single, for example, C program written. The amount of code here is gigantic compared to auditing one virtual machine and it will never be as secure. I'm not sure what your point is, but the former approach is obviously more secure and scalable. Why would you want to write program in a language that allows buffer overflows when you're concerned about security? It seems an obvious solution to me.
"I think you mean: It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the programming errors, incorrect assumptions, and random unexpected behaviour introduced through unforseen run-time activity it contains."
The fact is, the vast majority of security issues are caused by buffer overflow bugs. If you eliminate these types of bugs (which many languages do), you save a massive amount of maintenence time and effort.
A good start to our current security problem would be to stop writing internet based software in languages that allow buffer overflows to occur (e.g. C, C++). 90% of security exploits are caused by buffer overflows. I've seen a figure like this in research papers, but it should be obvious to anyone from reading patch descriptions and current security alters.
Writing computer programs in these types of languages and patching the errors as they are found is simply not a scalable solution. It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the buffer overflows it contains (e.g. the zlib bug, not a particular large library and it has been around for a long time). Picking a tool that doesn't even allow these types of errors is the obvious solution.
In addition, we need to start using more granular security permissions for our programs. Blaming security problems solely on users is ridiculous. Could you explain to me why a program downloaded from the internet has read and write access to every file on my computer? Why it can open up network connections? Having root users is a start, but we need to be able to sandbox all the applications we download so they just aren't allowed to do anything bad. I see no reason why a user shouldn't be able to download and run any program they find, as they should all be sandboxed appropriately that they cannot cause damage.
People might be interested in Krita (http://www.koffice.org/krita/screenshots.php) as an alternative to GIMP. It has an interface similar to PaintShop Pro where all the interface windows are contained within one main window and it integrates well with KDE.
Slashdot Mirror
> The formal specification was just as rigorous and complex as a computer program. The program became little more than a different expression of the formal specifications Have you got an example of this? The specification of what you want to do is generally significantly simpler than how you actually do something.
>Cuban medicine has shown for years that mother nature provides all kinds of wonderful molecules for free. They even have a >bio-version of Viagra. Problem is these things are not patentable. So a large medicinal company has to spend tons of money on >trials and FDA approval, and the very next day half a dozen competitors can throw a "me too" version on the market without >incurring those costs. Sorry for you if you have cancer, but don't hold your breath 'cause it ain't gonna happen. What you're saying simply isn't true. What Cuban medicine are you referring to by the way? I find it very hard to believe it isn't used in other countries if there is evidence it works. This is from the blog of a neuroscientist, who typically replies to pseudoscientific claims from alternative medicine advocates, with regard to your grossly simplified claims about cancer medicine. Summary: you can patent modified unpatentable products, the university/government carries out this research all the time (as shown by the article you replied to!), unpatentable products can be marketed in most countries with no research needed. http://www.theness.com/neurologicablog/default.asp?Display=101 "It is true that substances that can be obtained from nature without alteration cannot be patented you cannot patent a plant and that this reduces their profitability. But despite this, there are many studies into herbs and other widely used unpatentable products. Such studies are carried out by university based or government funded research...Further, regulations in the US and most other countries are such that unpatentable products can be marketed without requiring pre-market research. This is a huge advantage in the marketplace. The proof of the pudding is in the tasting the supplement industry has exploded to a multi-billion dollar industry. Also, there is no longer a distinction between the pharmaceutical industry and the supplement industry, and big pharma has learned there is money to be made in supplements. So it is not plausible to cry boo hoo about the poor oppressed natural product industry, when they are doing just fine, making billions, and even tempting the pharmaceutical industry to get in on the action. " http://www.theness.com/neurologicablog/default.asp?Display=28 "Yesterday Jeff asked, I just read a story about a new drug that apparently cures most types of cancers. The problem is that it is not patented so no drug company will pay for the trials. It just sounds too good to be true. Here is the link.... The bottom line is that if the science is solid and the potential very promising, the research will likely get done. Careers can be made from such research, universities could fund cancer centers and raise their prestige and profile, and there could also be a great deal of money to be made from such a treatment (even if it is not as much as from a patentable drug). There persists a nonsensical and very cynical myth that the medical establishment or the pharmaceutical industry already has a cure for cancer, but are suppressing it in order to protect their profits from treating (rather than curing) cancer. This episode shows, in my opinion, how silly that myth is. Researchers are doing university-based research to show the potential of a substance that cannot be patented as a cancer treatment. The research has been published and so is available to the public, and the media are spreading the word far and wide. No conspiracy has prevented this research from happening or knowledge of it from spreading."
> Any sort of technology is available for fraud, but this is 100x better
> then the signature security as well as the PIN is not transmitted past
> the terminal because it is all handled through the card. Basically the
> CHIP on the card is asked if the entered PIN is valid and the chip is
> responsible for authorizing it, not some remote system that needs to be
> verified with.
When a shop asks you to use chip in pin, you insert your card into a black box with numbers on it. You have no idea what this black box does. When you insert your card and type in your pin, it might only verify your transaction. Another thing it could do is scan and save the magnetic strip on your card and record your pin number. You would be none the wiser. Somebody could then create a copy of your card (minus chip) and then use it to withdraw cash from a cashpoint (possibly in another country).
How do you know if the machine handed to you won't do this? You can't; it's a fatally flawed system. It's similar to if a potential hacker asked you to use their keyboard to log into an account; there might be a hardware or a software keylogger running and you couldn't tell.
At least with a signature there is some way to prove that it wasn't you withdrawing the money and you don't go handing out your pin number to everyone. Your above description would sound good if the card actually contained the keypad, but the is provided by untrusted third parties.
"Some people actually work with .EXEs for a living. GMail is worthless to those people."
Don't you have a company email account for that? Gmail probably doesn't let you email 50+ people at a time to stop spammers abusing it. That would also fall under your "some people actually need to do this for a living" reasoning. The vast majority of people have no reason to email others .exe files, send mail to 50+ people at a time etc. so it makes sense to block these to prevent abuse.
Could anyone explain to me why backward compatability on a console is such a big deal? We didn't have it, for example, for the NES->SNES->Nintendo 64->Gamecube transitions and nobody really minded. If you already own XBOX games, you've already got a XBOX to play them on. I can't imagine many people want to buy old XBOX games for their brand new XBOX360 either. OK, some people might want to get the better known games (e.g. HALO) but it really isn't worth the hassle of backwards compatibility in my opinion. Isn't one of the advantages of consoles is that they have hardware that is more appropriate to pure gaming because they aren't constrained by ten years worth of old architecture (i.e. like the PC is)?
Exactly, there's nothing special about computer games that means they cannot be multi-threaded. It just so happens that all major game platforms have been single-threaded so far so programmers don't have much experience with it.
What the hell? Not a single XBox 360 programmer can work out how to create new threads and identify at least some processes that are not dependent one each other? That sounds like complete nonsense to me. There are plenty of easy ways to separate your level setup, game logic, sound processing, graphics, AI, physics etc. into different threads. I'm not saying taking full advantage of all cores is easy, but the idea that none of the game developers have the ability to use more than one thread is stupid.
One aspect that wasn't mentioned about Apple is vendor lock-in. In a couple of years, it is conceivable that some fantastic new type of MP3 device from another company will come out that lots of iPod users will want to switch to. When Joe the iPod user realises he has bought over $2000 worth of music from iTunes and he can't change to a non-Apple MP3 player because he can't play his music, he's going to be very annoyed. The majority of the population do not understand what DRM music and vendor lock-in means as they are merrily purchasing their MP3s from iTunes. This problem really needs to be addressed as Apple is selling the most downloaded music around and every track sold means they tighten their grip on the MP3 downloads/player market. Perhaps you could argue that they are leveraging their MP3 downloads market into the MP3 player market? Each product should be strong enough to compete on their own without this vendor lock-in to help as this hurts product quality and price for customers (they can't buy, say, cheaper DRMed MP3s from somewhere else because they can't play them and they can't switch music player because they can't play their current collection).
By the way, is there any need to write a one paragraph reply to every sentence from the OP? You should be able to articulate your position without having to do this; it's just excessive to take each sentence out of context and try to rip it to pieces. It looks like your trolling.
I always find it unfair when Linux distros are labelled poor because they don't support somebody's hardware, like their wireless card not working. The Linux developers would happily develop drivers for software if they were given the hardware specs to do so, but that isn't the case and drivers must be created with little help from the manufacturer. For example, I'm sure Novell would love to have native drivers for every wireless card out there, but if the companies won't co-operate, the best they can do is the ugly hack of using the win32 driver wrapped in an emulation layer. It's similar to complaining about why you can't play Playstation 2 games on Xbox hardware; the latter was never designed to work on the former and Microsoft wouldn't offer any help to get it working, but that doesn't mean Playstation 2 games are rubbish.
" I'll repeat what I've said before writing with a real string type in C, is not hard ... and provides all the same benifits. The problem is convincing people that it can be fast enough (and even now, speed outweighs security for most customers)."
A C program which meets the C language specification can contain buffer overflows so it simply does not have the same benefits as languages that do not allow buffer overflows. It doesn't matter if you can spend a lot of time writing a very secure C string type; you can easily create exploitable, difficult to find buffer overflows in the rest of the C code you write. It is insane that not using a buffer properly can allow a third party to take control of your computer. Why is using a language that lets this happen acceptable for writing secure programs?
A type-safe C program can contain buffer overflows. A type-safe Java, ML, OCaml, Haskell, Python, Cyclone etc. program cannot. Buffer overflows constitute 90% of the security problems found in todays software. Blaming the programmer for buffer overflows doesn't make sense, especially when expert users have these bugs in their code. You shouldn't be writing secure programs in a programming language that is fundamentally insecure.
All you need is one exploitable buffer overflow bug in an internet based program on your computer and your computer could get hacked, get a virus, get spyware etc. Expecting every programmer in the world to be good enough to not create buffer overflow bugs is not a realistic or scalable approach to this security problem.
"Sure, it may be a good start to remove some of the bugs, but who writes the sandbox? In what language? Is the sandbox itself sandboxed, to prevent being comprimised? If so, who writes that sandbox? In what language? Is that sandbox itself sandboxed, to prevent being comprimised? If so...
It's not an "obvious solution." It's an "obvious time-saver" when it comes to having to check for bugs."
To use Java as an example (I'm not advocating Java, just the idea), somebody writes a secure Java virtual machine once and everyone uses that as their platform. If a buffer overflow is found in the virtual machine (a single program), it is fixed once and all programs that use it are now more secure. The virtual machine code can also be heavily audited and over time it is unlikely to contain any easily exploitable security issues. With the current approach, buffer overflows need to be found and corrected in every single, for example, C program written. The amount of code here is gigantic compared to auditing one virtual machine and it will never be as secure. I'm not sure what your point is, but the former approach is obviously more secure and scalable. Why would you want to write program in a language that allows buffer overflows when you're concerned about security? It seems an obvious solution to me.
"I think you mean:
It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the programming errors, incorrect assumptions, and random unexpected behaviour introduced through unforseen run-time activity it contains."
The fact is, the vast majority of security issues are caused by buffer overflow bugs. If you eliminate these types of bugs (which many languages do), you save a massive amount of maintenence time and effort.
A good start to our current security problem would be to stop writing internet based software in languages that allow buffer overflows to occur (e.g. C, C++). 90% of security exploits are caused by buffer overflows. I've seen a figure like this in research papers, but it should be obvious to anyone from reading patch descriptions and current security alters. Writing computer programs in these types of languages and patching the errors as they are found is simply not a scalable solution. It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the buffer overflows it contains (e.g. the zlib bug, not a particular large library and it has been around for a long time). Picking a tool that doesn't even allow these types of errors is the obvious solution. In addition, we need to start using more granular security permissions for our programs. Blaming security problems solely on users is ridiculous. Could you explain to me why a program downloaded from the internet has read and write access to every file on my computer? Why it can open up network connections? Having root users is a start, but we need to be able to sandbox all the applications we download so they just aren't allowed to do anything bad. I see no reason why a user shouldn't be able to download and run any program they find, as they should all be sandboxed appropriately that they cannot cause damage.
People might be interested in Krita (http://www.koffice.org/krita/screenshots.php) as an alternative to GIMP. It has an interface similar to PaintShop Pro where all the interface windows are contained within one main window and it integrates well with KDE.