I'd like to see a study of the quality of PHP code that chimps write. Sadly enough, I expect it to be better than that of the typical 13-year-old PHP developer.
I wish I could say I was joking. But I cannot. Indeed, if my claims regarding PHP's insecurity seem grandiose, it is because PHP is that severely lacking. It's no secret that it suffers from very dangerous security issues. Go do some research for yourself on the many problems it suffers from, since it seems you won't take my word for it.
And yes, I am against insecure software such as PHP. But thankfully there are very good alternatives available. Ruby on Rails is one such alternative. I have no problem praising software that is well designed and well implemented. PHP is not such a piece of software.
Perhaps you are not willing to admit that PHP is so severely flawed because, as you say in your post, "PHP is one of my favorites." Admitting that software you like has poor security could very well hurt one's ego.
You obviously missed the point. I am talking about Perl 6. I'm not talking about Perl 5 and earlier.
Of course you'll find more information pertaining to Perl via a search engine. Then again, recall that Perl is older than Ruby, and hit widespread use before Ruby. Your findings are not surprising at all.
Don't forget that Java had Sun's marketing gorilla behind it. The industry was bombarded by Java hype, and thus people became very, very aware of it.
Ruby on Rails, on the other hand, has the force of the community behind it. It has become well-known due to word of mouth.
From my experience, many IT developers choose not to partake in software development after work. They'd rather to skiing, or watch TV, or play sports. Thus they tend to learn about new technologies only when their firm sends them to a training course. It's not surprising that they wouldn't have heard about it, especially if they're not actively involved with developing their own site.
A lot of people have begun moving away from Perl due to the slow development of Perl 6. Many are moving towards Ruby, which has drawn features and functionality quite well from Perl, and is currently moving at a quicker pace.
Now, that's not to say that Perl 6 may not encounter some degree of success in the future. Perl will most likely always have its users.
What the Perl 6 community might want to focus on now is developing the technology that will come after Ruby on Rails. Getting a step ahead in the web development arena may help bring users back to Perl from Ruby, Python and other languages and frameworks.
That could be a problem with your Firefox or Internet Explorer installation.
I'm using Konqueror, and it takes at most two seconds for their site to load. I cleared and then disabled the browser cache just to ensure that wasn't getting involved.
I just tried again a few seconds ago, and it's still very responsive, considering the load it is most likely under right now. Pages are loading in 2 seconds, if even that.
Remember, Ruby on Rails is designed to be very efficient. It's a solid piece of software used by many large users who put quite a load on it.
Only an individual new to the computing industry would put much faith in "momentum".
I've been around it for decades. I remember when Honeywell and Data General had "momentum". I'd be surprised if you've ever even seen a picture of their hardware.
A bit later there was CP/M. And Apple. Apple had much "momentum" in the 1980s, only to almost hit rock bottom. At least they've been able to pick themselves up again.
There was even talk this morning about Java losing its "momentum".
Ruby on Rails could very well overtake PHP quite quickly.
While some onus does rest on developers to develop quality code, that does not mean that the language and any implementations should not take steps to limit the ability of the programmer to write faulty code.
That holds especially true for languages that are used in hostile environments, such as the WWW. Considering that Web development is touted as PHP's strong point, one would think it would have excellent security. Of course, we know from experience that that is not the case.
Ruby won't necessarily make your code perfect. But Ruby, along with sound development techniques (unit testing, for example), will result in very secure applications. The use of PHP, on the other hand, is basically an invitation for security issues. It is not a well designed language, and it is not well implemented.
However, many of the problems associated with PHP are just due to flaws in the design of PHP. It's more a case of PHP being worse than it should be, rather than Ruby on Rails being extremely secure.
That said, most Ruby on Rails-related code is written by far more experienced developers. As would be expected, the quality of the code is higher, and the likelyhood of security issues is vastly reduced. The trend in the Ruby community to heavily use unit testing also helps ensure that quality is a paramount consideration.
Can you provide links to some software that you have written, for us to stress test?
There is a very good chance that we could, to put it nicely, molest the fucking guts right out of your software.
Ruby on Rails is being used by many people, and it is maturing very rapidly. It's that sort of real-world use that results in well-written, stable, secure software. Not only that, but Ruby developers are on the leading edge of agile development methods. They're amongst the most experienced users of unit testing, for instance.
Other projects, such as PHP, could really learn a lesson in effective software design from the Ruby community.
That's a far higher standard than you'll find used by most commercial developers.
Remember, Ruby is at the forefront of the agile development community. Many developments in unit testing, for instance, directly involve Ruby. Ruby developers are often the most experienced at effectively employing such development techniques.
And you know what? It shows. Ruby software is often of extremely high quality. It's not perfect, but there is much effort taken to ensure correctly-functioning code.
Ruby on Rails provides a far superior solution for web sites than PHP in many cases. It would be excellent if it ended up usurping PHP for most PHP-based sites.
PHP's bad reputation with regards to its security is, unfortunately, harming the open source community. Managers who are considering switching to open source solutions are hearing about the security flaws in PHP, and mistakenly thinking that Apache, MySQL and Linux are insecure (due to the popular 'LAMP' association). Of course, that isn't the case by a long shot.
Regardless of what people switch to, the main focus needs to be on moving away from PHP. Ruby on Rails provides a rapidly maturing alternative for building all sorts of web sites.
Re:PHP is not good for the open source community.
on
Java Is So 90s
·
· Score: 0, Troll
If such an opportunity arose, I would go for it. Plus I'm excellent for such work. Since I suffer from severe impotency, I would not get the distracting erections that many younger men would get when subjected to hours of pornography viewing.
Re:PHP is not good for the open source community.
on
Java Is So 90s
·
· Score: 1
I'm retired. I still do some consulting, mostly just for the hell of it, however. It keeps me up to date with the latest developments.
Re:PHP is not good for the open source community.
on
Java Is So 90s
·
· Score: 1
Either way, be it PHP or faulty PHP scripts, it is PHP which is giving the entire open source community a very bad image.
Also, it doesn't matter how stupid such a manager is. Like it or not, they're the ones making the decisions. And if they incorrectly hear that Linux, Apache and MySQL are insecure just because of problems with poorly written PHP scripts, PHP is to blame for the bad image.
The one manager I mentioned actually had no contract with Microsoft, contrary to your incorrect assumption. They had been using HP systems for decades, but wanted to get away from HP-UX.
PHP is not good for the open source community.
on
Java Is So 90s
·
· Score: -1
Advocates of PHP often point to its ease of use and rapid development capabilities as being beneficial. But as with many benefits, there are often serious drawbacks. One such drawback is the security of PHP applications; it is often lacking, if not completely broken. Regardless of whether you want to blame inexperienced programmers or the developers of PHP, the fact remains that the use of PHP is a security debacle waiting to happen.
An even bigger problem arises when it is combined with Linux, Apache and MySQL to form one of the possible 'LAMP' combinations. The association created there sticks in a lot of people, especially those unfamiliar with the products. They think that Linux is Apache is MySQL is PHP. They can't tell them apart. This becomes problematic when PHP encounters a serious security issue, which does happen quite often. Managers hear about web sites being compromised due to PHP glitches, and it sticks in their mind.
I dealt with one IT manager who flat out told me that Linux and Apache were insecure because of PHP. I was shocked at that prospect. We all know that Apache and Linux, while not perfect, are very reasonably secure systems. Unfortunately, I've heard similar ideas come from a number of IT technicians, as well.
Like it or not, PHP is giving the entire open source community a bad image. That holds especially true for the projects that it is often linked with via 'LAMP': Linux, Apache and MySQL. It is quite possible that the adoption of such open source technologies has been negatively affected by their association with the ill-reputed PHP.
It may even be time for the Apache, MySQL and Linux developers to take a stand against PHP. That's not to say that they should outright demand an end to the product. But they should, however, put serious pressure on the PHP developers to shape up their act. The PHP project needs to put out far more stable, secure, and sound software releases.
I'll have to contact them to see if they're willing to make that material available.
Indeed, it was very interesting to see how poorly GNOME fared. I'm not even sure if the problems can be rectified. Some of the productivity issues, such as the terrible GNOME 2.12 file selector, seem to be supported and encouraged by at least some of the more influential GNOME developers.
Part of the problem may also be the involvement of Red Hat. There have been serious questions raised concerning the quality of the Red Hat developments. Between RPM, the GCC 2.96 debacle, their less-than-helpful GNOME and GTK+ contributions, and the quite unstable and faulty Fedora Core, they have a very poor track record.
Meanwhile, a distribution like SuSE has provided a solid, working KDE-based desktop/workstation system for years. Some have suggested that it's a European/American dichotomy at work. GNOME, which is mainly written by North Americans, has had serious quality issues. KDE, which is mainly developed by Europeans, has a far higher quality. Of course, we may have to wait somewhat longer to see what will happen now that SuSE has been acquired by Novell. If we see a sharp decline in the quality of SuSE, then it may be due to shoddy American software development.
Can you run the most recent distributed.net client for this system, and provide us with the typical keys/second value you obtain?
While not a perfect benchmark by any means, and highly dependent upon which core is used (ie. the algorithm and implementation), it is often a useful test to quantify how a machine performs.
Re:A simple programming language would have been b
on
The Future of HTML
·
· Score: 0, Troll
He should have developed a JavaScript-like solution half a decade before JavaScript was made available? Do you understand how fucking stupid that idea makes you sound?
With regards to KDE versus GNOME, the best thing to do is let nature take its course. What I mean by that is let people use which one they prefer. From past experience, those who use KDE end up being more productive. And increased productivity often times leads to increased financial success.
I recently did some consulting for a firm which allowed their developers and administrative staff to use GNOME or KDE. It was each employee's choice which to use. When review time came around, a study was done into which desktop was used by the most productive users.
By far the most productive users, both developers and secretaries/financial officers/etc., were those who used KDE and related software, such as KOffice. The developers who used KDE were the ones who wrote the code with the fewest number of bugs, and the secretaries who used KDE were the ones who were able to produce letters and documents with the fewest drafts.
There was one notable exception, however. One developer who reported using GNOME was amongst the top three (I believe it was) developers. Further investigation revealed that while he was using GNOME, it was only as a program launcher. He was using KDevelop, Konqueror and other KDE software while working.
Overall, they weren't sure if it was a matter of productive people choosing KDE, or KDE allowing people to be more productive. I instinctively feel it was some of both.
The best thing to do is let people use what they want. In the end, their choice will either help or hinder their productivity. Those who are no productive will lose their jobs, and slide into irrelevancy, leaving only the productive. From my past experiences, it would appear that GNOME has become the least productive of the two desktops.
Do you know how many people it will take to actually affect Sony's bottom line? Far, far more people than currently know about this whole debacle.
Please stop living in such a sheltered world. Just because most people at Slashdot are aware of the situation does not mean that everyone else is. And almost everyone else will continue to buy Sony products, even if a few hundred people who visit this site do not.
Slashdot Mirror
Maybe the children were from Kansas. The rules of science are null and void in Kansas.
Are you suggesting that the US staff its military with chimps instead of people? And what exactly is the change there? Do chimps not torture as often?
The chimp would probably eat the child, just so it doesn't get stuck doing pointless experiments.
I'd like to see a study of the quality of PHP code that chimps write. Sadly enough, I expect it to be better than that of the typical 13-year-old PHP developer.
I wish I could say I was joking. But I cannot. Indeed, if my claims regarding PHP's insecurity seem grandiose, it is because PHP is that severely lacking. It's no secret that it suffers from very dangerous security issues. Go do some research for yourself on the many problems it suffers from, since it seems you won't take my word for it.
And yes, I am against insecure software such as PHP. But thankfully there are very good alternatives available. Ruby on Rails is one such alternative. I have no problem praising software that is well designed and well implemented. PHP is not such a piece of software.
Perhaps you are not willing to admit that PHP is so severely flawed because, as you say in your post, "PHP is one of my favorites." Admitting that software you like has poor security could very well hurt one's ego.
You obviously missed the point. I am talking about Perl 6. I'm not talking about Perl 5 and earlier.
Of course you'll find more information pertaining to Perl via a search engine. Then again, recall that Perl is older than Ruby, and hit widespread use before Ruby. Your findings are not surprising at all.
Don't forget that Java had Sun's marketing gorilla behind it. The industry was bombarded by Java hype, and thus people became very, very aware of it.
Ruby on Rails, on the other hand, has the force of the community behind it. It has become well-known due to word of mouth.
From my experience, many IT developers choose not to partake in software development after work. They'd rather to skiing, or watch TV, or play sports. Thus they tend to learn about new technologies only when their firm sends them to a training course. It's not surprising that they wouldn't have heard about it, especially if they're not actively involved with developing their own site.
A lot of people have begun moving away from Perl due to the slow development of Perl 6. Many are moving towards Ruby, which has drawn features and functionality quite well from Perl, and is currently moving at a quicker pace.
Now, that's not to say that Perl 6 may not encounter some degree of success in the future. Perl will most likely always have its users.
What the Perl 6 community might want to focus on now is developing the technology that will come after Ruby on Rails. Getting a step ahead in the web development arena may help bring users back to Perl from Ruby, Python and other languages and frameworks.
That could be a problem with your Firefox or Internet Explorer installation.
I'm using Konqueror, and it takes at most two seconds for their site to load. I cleared and then disabled the browser cache just to ensure that wasn't getting involved.
I just tried again a few seconds ago, and it's still very responsive, considering the load it is most likely under right now. Pages are loading in 2 seconds, if even that.
Remember, Ruby on Rails is designed to be very efficient. It's a solid piece of software used by many large users who put quite a load on it.
Only an individual new to the computing industry would put much faith in "momentum".
I've been around it for decades. I remember when Honeywell and Data General had "momentum". I'd be surprised if you've ever even seen a picture of their hardware.
A bit later there was CP/M. And Apple. Apple had much "momentum" in the 1980s, only to almost hit rock bottom. At least they've been able to pick themselves up again.
There was even talk this morning about Java losing its "momentum".
Ruby on Rails could very well overtake PHP quite quickly.
While some onus does rest on developers to develop quality code, that does not mean that the language and any implementations should not take steps to limit the ability of the programmer to write faulty code.
That holds especially true for languages that are used in hostile environments, such as the WWW. Considering that Web development is touted as PHP's strong point, one would think it would have excellent security. Of course, we know from experience that that is not the case.
Ruby won't necessarily make your code perfect. But Ruby, along with sound development techniques (unit testing, for example), will result in very secure applications. The use of PHP, on the other hand, is basically an invitation for security issues. It is not a well designed language, and it is not well implemented.
There is no need to spread disinformation. Their site is working just fine. I even cleared my cache, just to be sure that I'm fetching a new copy.
Not directly.
However, many of the problems associated with PHP are just due to flaws in the design of PHP. It's more a case of PHP being worse than it should be, rather than Ruby on Rails being extremely secure.
That said, most Ruby on Rails-related code is written by far more experienced developers. As would be expected, the quality of the code is higher, and the likelyhood of security issues is vastly reduced. The trend in the Ruby community to heavily use unit testing also helps ensure that quality is a paramount consideration.
Can you provide links to some software that you have written, for us to stress test?
There is a very good chance that we could, to put it nicely, molest the fucking guts right out of your software.
Ruby on Rails is being used by many people, and it is maturing very rapidly. It's that sort of real-world use that results in well-written, stable, secure software. Not only that, but Ruby developers are on the leading edge of agile development methods. They're amongst the most experienced users of unit testing, for instance.
Other projects, such as PHP, could really learn a lesson in effective software design from the Ruby community.
There is a list of users at:
http://www.rubyonrails.org/applications
That's a far higher standard than you'll find used by most commercial developers.
Remember, Ruby is at the forefront of the agile development community. Many developments in unit testing, for instance, directly involve Ruby. Ruby developers are often the most experienced at effectively employing such development techniques.
And you know what? It shows. Ruby software is often of extremely high quality. It's not perfect, but there is much effort taken to ensure correctly-functioning code.
Ruby on Rails provides a far superior solution for web sites than PHP in many cases. It would be excellent if it ended up usurping PHP for most PHP-based sites.
PHP's bad reputation with regards to its security is, unfortunately, harming the open source community. Managers who are considering switching to open source solutions are hearing about the security flaws in PHP, and mistakenly thinking that Apache, MySQL and Linux are insecure (due to the popular 'LAMP' association). Of course, that isn't the case by a long shot.
Regardless of what people switch to, the main focus needs to be on moving away from PHP. Ruby on Rails provides a rapidly maturing alternative for building all sorts of web sites.
If such an opportunity arose, I would go for it. Plus I'm excellent for such work. Since I suffer from severe impotency, I would not get the distracting erections that many younger men would get when subjected to hours of pornography viewing.
I'm retired. I still do some consulting, mostly just for the hell of it, however. It keeps me up to date with the latest developments.
Either way, be it PHP or faulty PHP scripts, it is PHP which is giving the entire open source community a very bad image.
Also, it doesn't matter how stupid such a manager is. Like it or not, they're the ones making the decisions. And if they incorrectly hear that Linux, Apache and MySQL are insecure just because of problems with poorly written PHP scripts, PHP is to blame for the bad image.
The one manager I mentioned actually had no contract with Microsoft, contrary to your incorrect assumption. They had been using HP systems for decades, but wanted to get away from HP-UX.
Advocates of PHP often point to its ease of use and rapid development capabilities as being beneficial. But as with many benefits, there are often serious drawbacks. One such drawback is the security of PHP applications; it is often lacking, if not completely broken. Regardless of whether you want to blame inexperienced programmers or the developers of PHP, the fact remains that the use of PHP is a security debacle waiting to happen.
An even bigger problem arises when it is combined with Linux, Apache and MySQL to form one of the possible 'LAMP' combinations. The association created there sticks in a lot of people, especially those unfamiliar with the products. They think that Linux is Apache is MySQL is PHP. They can't tell them apart. This becomes problematic when PHP encounters a serious security issue, which does happen quite often. Managers hear about web sites being compromised due to PHP glitches, and it sticks in their mind.
I dealt with one IT manager who flat out told me that Linux and Apache were insecure because of PHP. I was shocked at that prospect. We all know that Apache and Linux, while not perfect, are very reasonably secure systems. Unfortunately, I've heard similar ideas come from a number of IT technicians, as well.
Like it or not, PHP is giving the entire open source community a bad image. That holds especially true for the projects that it is often linked with via 'LAMP': Linux, Apache and MySQL. It is quite possible that the adoption of such open source technologies has been negatively affected by their association with the ill-reputed PHP.
It may even be time for the Apache, MySQL and Linux developers to take a stand against PHP. That's not to say that they should outright demand an end to the product. But they should, however, put serious pressure on the PHP developers to shape up their act. The PHP project needs to put out far more stable, secure, and sound software releases.
I'll have to contact them to see if they're willing to make that material available.
Indeed, it was very interesting to see how poorly GNOME fared. I'm not even sure if the problems can be rectified. Some of the productivity issues, such as the terrible GNOME 2.12 file selector, seem to be supported and encouraged by at least some of the more influential GNOME developers.
Part of the problem may also be the involvement of Red Hat. There have been serious questions raised concerning the quality of the Red Hat developments. Between RPM, the GCC 2.96 debacle, their less-than-helpful GNOME and GTK+ contributions, and the quite unstable and faulty Fedora Core, they have a very poor track record.
Meanwhile, a distribution like SuSE has provided a solid, working KDE-based desktop/workstation system for years. Some have suggested that it's a European/American dichotomy at work. GNOME, which is mainly written by North Americans, has had serious quality issues. KDE, which is mainly developed by Europeans, has a far higher quality. Of course, we may have to wait somewhat longer to see what will happen now that SuSE has been acquired by Novell. If we see a sharp decline in the quality of SuSE, then it may be due to shoddy American software development.
Can you run the most recent distributed.net client for this system, and provide us with the typical keys/second value you obtain?
While not a perfect benchmark by any means, and highly dependent upon which core is used (ie. the algorithm and implementation), it is often a useful test to quantify how a machine performs.
He should have developed a JavaScript-like solution half a decade before JavaScript was made available? Do you understand how fucking stupid that idea makes you sound?
With regards to KDE versus GNOME, the best thing to do is let nature take its course. What I mean by that is let people use which one they prefer. From past experience, those who use KDE end up being more productive. And increased productivity often times leads to increased financial success.
I recently did some consulting for a firm which allowed their developers and administrative staff to use GNOME or KDE. It was each employee's choice which to use. When review time came around, a study was done into which desktop was used by the most productive users.
By far the most productive users, both developers and secretaries/financial officers/etc., were those who used KDE and related software, such as KOffice. The developers who used KDE were the ones who wrote the code with the fewest number of bugs, and the secretaries who used KDE were the ones who were able to produce letters and documents with the fewest drafts.
There was one notable exception, however. One developer who reported using GNOME was amongst the top three (I believe it was) developers. Further investigation revealed that while he was using GNOME, it was only as a program launcher. He was using KDevelop, Konqueror and other KDE software while working.
Overall, they weren't sure if it was a matter of productive people choosing KDE, or KDE allowing people to be more productive. I instinctively feel it was some of both.
The best thing to do is let people use what they want. In the end, their choice will either help or hinder their productivity. Those who are no productive will lose their jobs, and slide into irrelevancy, leaving only the productive. From my past experiences, it would appear that GNOME has become the least productive of the two desktops.
Do you know how many people it will take to actually affect Sony's bottom line? Far, far more people than currently know about this whole debacle.
Please stop living in such a sheltered world. Just because most people at Slashdot are aware of the situation does not mean that everyone else is. And almost everyone else will continue to buy Sony products, even if a few hundred people who visit this site do not.