well this is true and not true. Money saved is most definitely not the only talking point. Talk about security. Talk about cross platform functionality and open standards (after all alot of students use Mac and some use Linux too). They want a system that is secure, costs less but also works with all computers being brought into the network. Open source supports open standards, is more often cross platform and easier to secure. Not to mention it is often free.
Seriously, I'd be one of them exploding with rage but it would be a good idea if they did it. Still it won't be done because they'd have alot of rearchitecturing to do of their entire product line. It would take them YEARS.
Well the other resellers might have them but companies would rather purchase a distro from the source thats supports MS products. Made by Microsoft for Microsoft. They've been eating the MS dogfood so long they don't know any better.
It would make more sense if they released their own version of Linux. They could EASILY sell support, books and rake in money for it. and if they sold their apps for Linux, again, they would have a huge market as their product would run on Macs as well with little re-engineering.
The damage they would do to the other Linux resellers would be enormous (in the short term) and if they could do a good enough job, they could become a huge longterm player and maybe even kill off the other players.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
That's even less useful, because then you're just comparing a well integrated Apache module to basically nothing. There are well defined deployment solutions for Rails, not so much for Ruby without a framework.
An apache module??? What are you talking about? Perl, Python and PHP vs Ruby??? You selected ONE while I am broadly comparing and naming examples. But to go with your example, I believe you are talking about PHP which was designed to be used as an Apache Module and not as a standalone and as such will always suffer a startup loss of time vs any language since it does not stay running as a daemon in the background. Hence people benchmark it as an Apache module.
Now back to less whining and more comparing of languages...
servers are still cheaper than developers...
And sys admins are to maintain all those those servers you are buying are equally cheap. How about the DBA's? etc etc. Everytime you overly complicate your architecture, you extend your cost. The Ruby answer has always been 'so we're slow... throw hardware at the answer' and that has not been a solution for companies that get to a medium size and can no longer afford maintenance or the staff to maintain.
Additionally, Ruby devs seem to think they have a 'MAGIC LANGUAGE' that allows them to develop so fast that all other languages are absolete. Got news for you... all languages have MVC frameworks, all languages can use patterns. These are not new concepts. Ruby is not fast for development. It is merely fast for newbies picking up a language who have never programmed before. And that's even more dangerous because they don't understand the fundamentals of what they are doing.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
But now you are comparing RoR (language + framework) to PHP (language). Bad comparison. Thats like comparing a submarine to a volkswagon. I was strictly comparing languages based upon benchmarks of the languages and NOT the frameworks.
I'm willing to take a second look at Ruby but to date it has always come second as a web language for speed, scalability. And the only argument people provide for using it is 'you can develop faster'; well you can in ANY language given a good framework, proper training, knowledge of patterns, etc etc. The thing Ruby DOES provide that enable you to develop faster (like obfuscating looping and stuff like that) unfortunately is also it's achilles heel and causes extra processing to occur causing it to be slower than other languages doing the same tasks.
Now speed and scaling may not be top on your list but when you get your product built and you start to get popular and are getting a couple million hits a day and can't afford all that new hardware yet, and the platform you chose can't keep up, then it becomes an issue. This is why people make a big deal about it. Having working for Amazon as a startup, we doubled our business every month for the first two years from 95-97!!! Ruby would never have been able to accomplish that and we would have had to constantly be replacing and buying hardware. There has to be a stabilization point.
For now, Ruby is GREAT as a small mom-n-pop solution and for smaller shops that don't expect big growth (as long as they can find the developers and tools). But it is not yet ready for large to enterprise deployment and even for that reason, I would stay away from it for medium size businesses due to expected growth. However, with every iteration, it is becoming more and more mature and I expect they will work through these issues in the next 3-5 major releases.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
Scaling isn't a language issue normally but in the case of Ruby, it seems to have an inherent flaw with it's threads which causes it to 'top out' in comparison to other languages; while PHP, Perl and Python continue to fulfill requests, Ruby 'tops out'. For example, as PHP determines a need for more processes, it scales up to handle more concurrent requests. Ruby can't and will top out and just queue them up.
Getting more done with less is great no matter what the language and this can be done in all languages... it's called a framework, libraries, patterns and experience. But that has nothing to do with what we are talking about. We were talking about scaling not a languages usability.
Ruby is not inherently slow just the current implementation is somewhat slow.
No.. just it's last SEVERAL incarnations that have been slow. That and a bunch of empty promises of how it will be faster and more scalable. One of these days they may deliver but by that time the other languages will most likely hav doubled THEIR speeds.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
Hardware is cheap. Couldn't you throw more at the problem?
I hear that answer alot from the RUBY community. Why would I as a business be expected to switch to a language that requires twice as much hardware? What you MAY save with software dev speed, you now lose with day to day server maintenance.
The key to good engineering is to simplify because the more parts, the more chance of failure. So throwing more hardware at the issue when similar languages such as PHP, PERL and PYTHON can do it with far less hardware is not a very good solution.
So in other words... if you want something decent and fast, use Java???
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 2, Interesting
That's an oversimplification of the issue. You don't simply use a new tool because it CAN do something, it is also a matter of whether it can do it BETTER that the current tool, whether you can find people who can use that tool, whether you can find information on how to use that tool with other systems and tools and whether that tools has a robust set of expansions/libraries/modules.
To date for alot of people and companies, RUBY was hype (and this has alot to do with the community that hyped it). Now that the hype is over, people are beginning to evaluate it for what it is. RUBY can provide an easy entry level, is a powerful language but has not to date shown it's ability to scale, continues to rely HEAVILY on languages that it's community says it is much better than in order to scale (ie PHP, Perl, Python), and the benchmarks I have seen are always slanted (ie trying to test pageload times for PHP vs RUBY without installing PHP as an Apache Module).
So the correct phrase should be... The right tool for the job (given current employment pool capable of supporting said tool and community support for said tool).
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
Rubys speed and scalability hasn't compared in the past but each iteration I always try to re-evaluate and give it another shot. The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
My company tried to make the switch and could find enough developers, could find enough module support and just couldn't get the same functionality for RUBY as with languages that have larger communities. Plus under large loads, it buckled and we ended up having to rely upon the same PHP codebase to get the job done anyway.
But again, a new iteration may mean improvements and who knows, they may have made some positive changes this time. Naturally it won't have all the support of more mature languages but all I expect is for it to be able to scale as well and handle page loads as well before I'm switching languages.
And you neglect to point out that it did nothing and that UNIX systems were the first to learn how to protect against worms as a result. But did Mcrosoft choose to learn from the lessons of it's predecessors? No. It chose to ignore successful security methodologies in order to allow open communications between all software systems, api's and the user. The system was designed to be open by default... not secure. Security was ALWAYS an afterthought.
No they weren't bugged or monitored as far as you could see but they were quickly carted away for' re-education' after speaking with you anything negatively about China.
Yes yes, China is good. These communications are not being monitored. My family will not be sent to reeducation if I say these things. You mustn't help me immediately and get me out of here. We are not slaves. Yay CHINA!
So there can't be 300.000 people who would favor Chinese and the Government runs them?
You know, I suspect a cold war like propaganda against China too, in some occasions at least.
I agree comrade. There seem many thing like me agree with Chinese government good. You too like government chinese. Eat yum yum.
It was recently reported that the Chinese government pays 300,000 astroturfers to go online and talk positively about the Chinese and the chinese government. Basically a modern day propoganda campain (melamine and lead based toys sold separately).
My friend, Lets call him Mr Soon-To-Be-Laid-Off-From-Microsoft (Yes, I work across the street from Redmond), has tested Windows 7 as well and while he points to it being able to run on some machines that run XP, it has specs more along the lines of Vista and guarantees me that there WILL be more bloat put into the final product; Mr STBLOFM pointed out to me that the last few betas of their OS have always run faster than their final product because they consider their beta part of their markleting pitch. They want people to think it is faster than the final product will actually be so they leave out key elements that will slow the system down, hog resources, etc.
When the final product ships, expect it to hog far more resources than you are seeing in beta. It happened with XP and VISTA and there is no reason to think it won't happen with Windows 7 especially since it too is based upon VISTA.
A BETA is not the complete product. It is a well known fact that BETAS always run smoother than the final product. Microsoft betas of VISTA had the same results. They have yet to add in the bloat to the final product that is going to slow it down. This is why it is BETA and not a final product.
Slashdot Mirror
well this is true and not true. Money saved is most definitely not the only talking point. Talk about security. Talk about cross platform functionality and open standards (after all alot of students use Mac and some use Linux too). They want a system that is secure, costs less but also works with all computers being brought into the network. Open source supports open standards, is more often cross platform and easier to secure. Not to mention it is often free.
I wonder if their documentation will be written in whitespace.
Seriously, I'd be one of them exploding with rage but it would be a good idea if they did it. Still it won't be done because they'd have alot of rearchitecturing to do of their entire product line. It would take them YEARS.
Well the other resellers might have them but companies would rather purchase a distro from the source thats supports MS products. Made by Microsoft for Microsoft. They've been eating the MS dogfood so long they don't know any better.
It would make more sense if they released their own version of Linux. They could EASILY sell support, books and rake in money for it. and if they sold their apps for Linux, again, they would have a huge market as their product would run on Macs as well with little re-engineering.
The damage they would do to the other Linux resellers would be enormous (in the short term) and if they could do a good enough job, they could become a huge longterm player and maybe even kill off the other players.
An apache module??? What are you talking about? Perl, Python and PHP vs Ruby??? You selected ONE while I am broadly comparing and naming examples. But to go with your example, I believe you are talking about PHP which was designed to be used as an Apache Module and not as a standalone and as such will always suffer a startup loss of time vs any language since it does not stay running as a daemon in the background. Hence people benchmark it as an Apache module.
Now back to less whining and more comparing of languages...
And sys admins are to maintain all those those servers you are buying are equally cheap. How about the DBA's? etc etc. Everytime you overly complicate your architecture, you extend your cost. The Ruby answer has always been 'so we're slow... throw hardware at the answer' and that has not been a solution for companies that get to a medium size and can no longer afford maintenance or the staff to maintain.
Additionally, Ruby devs seem to think they have a 'MAGIC LANGUAGE' that allows them to develop so fast that all other languages are absolete. Got news for you... all languages have MVC frameworks, all languages can use patterns. These are not new concepts. Ruby is not fast for development. It is merely fast for newbies picking up a language who have never programmed before. And that's even more dangerous because they don't understand the fundamentals of what they are doing.
I wonder if the investigating police showed up in Enterprise Uniforms. 'This is highly illogical, Leutenant'
Register itunesproxy.com before apple does!!!
But now you are comparing RoR (language + framework) to PHP (language). Bad comparison. Thats like comparing a submarine to a volkswagon. I was strictly comparing languages based upon benchmarks of the languages and NOT the frameworks.
I'm willing to take a second look at Ruby but to date it has always come second as a web language for speed, scalability. And the only argument people provide for using it is 'you can develop faster'; well you can in ANY language given a good framework, proper training, knowledge of patterns, etc etc. The thing Ruby DOES provide that enable you to develop faster (like obfuscating looping and stuff like that) unfortunately is also it's achilles heel and causes extra processing to occur causing it to be slower than other languages doing the same tasks.
Now speed and scaling may not be top on your list but when you get your product built and you start to get popular and are getting a couple million hits a day and can't afford all that new hardware yet, and the platform you chose can't keep up, then it becomes an issue. This is why people make a big deal about it. Having working for Amazon as a startup, we doubled our business every month for the first two years from 95-97!!! Ruby would never have been able to accomplish that and we would have had to constantly be replacing and buying hardware. There has to be a stabilization point.
For now, Ruby is GREAT as a small mom-n-pop solution and for smaller shops that don't expect big growth (as long as they can find the developers and tools). But it is not yet ready for large to enterprise deployment and even for that reason, I would stay away from it for medium size businesses due to expected growth. However, with every iteration, it is becoming more and more mature and I expect they will work through these issues in the next 3-5 major releases.
Scaling isn't a language issue normally but in the case of Ruby, it seems to have an inherent flaw with it's threads which causes it to 'top out' in comparison to other languages; while PHP, Perl and Python continue to fulfill requests, Ruby 'tops out'. For example, as PHP determines a need for more processes, it scales up to handle more concurrent requests. Ruby can't and will top out and just queue them up. Getting more done with less is great no matter what the language and this can be done in all languages... it's called a framework, libraries, patterns and experience. But that has nothing to do with what we are talking about. We were talking about scaling not a languages usability.
No.. just it's last SEVERAL incarnations that have been slow. That and a bunch of empty promises of how it will be faster and more scalable. One of these days they may deliver but by that time the other languages will most likely hav doubled THEIR speeds.
I hear that answer alot from the RUBY community. Why would I as a business be expected to switch to a language that requires twice as much hardware? What you MAY save with software dev speed, you now lose with day to day server maintenance.
The key to good engineering is to simplify because the more parts, the more chance of failure. So throwing more hardware at the issue when similar languages such as PHP, PERL and PYTHON can do it with far less hardware is not a very good solution.
So in other words... if you want something decent and fast, use Java???
That's an oversimplification of the issue. You don't simply use a new tool because it CAN do something, it is also a matter of whether it can do it BETTER that the current tool, whether you can find people who can use that tool, whether you can find information on how to use that tool with other systems and tools and whether that tools has a robust set of expansions/libraries/modules.
To date for alot of people and companies, RUBY was hype (and this has alot to do with the community that hyped it). Now that the hype is over, people are beginning to evaluate it for what it is. RUBY can provide an easy entry level, is a powerful language but has not to date shown it's ability to scale, continues to rely HEAVILY on languages that it's community says it is much better than in order to scale (ie PHP, Perl, Python), and the benchmarks I have seen are always slanted (ie trying to test pageload times for PHP vs RUBY without installing PHP as an Apache Module).
So the correct phrase should be... The right tool for the job (given current employment pool capable of supporting said tool and community support for said tool).
Rubys speed and scalability hasn't compared in the past but each iteration I always try to re-evaluate and give it another shot. The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
My company tried to make the switch and could find enough developers, could find enough module support and just couldn't get the same functionality for RUBY as with languages that have larger communities. Plus under large loads, it buckled and we ended up having to rely upon the same PHP codebase to get the job done anyway.
But again, a new iteration may mean improvements and who knows, they may have made some positive changes this time. Naturally it won't have all the support of more mature languages but all I expect is for it to be able to scale as well and handle page loads as well before I'm switching languages.
And you neglect to point out that it did nothing and that UNIX systems were the first to learn how to protect against worms as a result. But did Mcrosoft choose to learn from the lessons of it's predecessors? No. It chose to ignore successful security methodologies in order to allow open communications between all software systems, api's and the user. The system was designed to be open by default... not secure. Security was ALWAYS an afterthought.
No they weren't bugged or monitored as far as you could see but they were quickly carted away for' re-education' after speaking with you anything negatively about China.
Yes yes, China is good. These communications are not being monitored. My family will not be sent to reeducation if I say these things. You mustn't help me immediately and get me out of here. We are not slaves. Yay CHINA!
I agree comrade. There seem many thing like me agree with Chinese government good. You too like government chinese. Eat yum yum.
It was recently reported that the Chinese government pays 300,000 astroturfers to go online and talk positively about the Chinese and the chinese government. Basically a modern day propoganda campain (melamine and lead based toys sold separately).
Turing the lexicon? What a test.
My friend, Lets call him Mr Soon-To-Be-Laid-Off-From-Microsoft (Yes, I work across the street from Redmond), has tested Windows 7 as well and while he points to it being able to run on some machines that run XP, it has specs more along the lines of Vista and guarantees me that there WILL be more bloat put into the final product; Mr STBLOFM pointed out to me that the last few betas of their OS have always run faster than their final product because they consider their beta part of their markleting pitch. They want people to think it is faster than the final product will actually be so they leave out key elements that will slow the system down, hog resources, etc.
When the final product ships, expect it to hog far more resources than you are seeing in beta. It happened with XP and VISTA and there is no reason to think it won't happen with Windows 7 especially since it too is based upon VISTA.
Never heard of wordplay? So sad. Literacy is wasted on you.
And one more person who proves my sig for me.
That's not your left nut. That's your head. Disgust.
A BETA is not the complete product. It is a well known fact that BETAS always run smoother than the final product. Microsoft betas of VISTA had the same results. They have yet to add in the bloat to the final product that is going to slow it down. This is why it is BETA and not a final product.