Agreed, I track the CentOS and Ubuntu security lists to know when to reboot my services, and chances vulnerabilities for various libraries are much more common than other stuff. That said, a lot of the time you can get away with just restarting a service or two.
I'd put this service in the category of things that'd be nice to have, I'd consider paying $4/mo for it. Of course, if you really 'need' this service what you probably actually need is a hot spare with automatic failover.
Eeesh, what a tragedy. I got the same BS at my job, luckily my higher up was fired and I replaced him, letting me turn our crapload of PHP into Rails.
I took a good long look at the PHP MVC world when it was clear my company wasn't going to drink the Rails kool aid, and I have to say, none of the PHP frameworks were (at the time, 2 years ago) up to snuff compared to Rails. They were just flat out missing a lot of the features that made Rails great.
Plus, it takes me way less time to code in Ruby than PHP, PHP just takes more LoC, especially as your app's complexity increases.
Hey, I agree, I wrote that post as a joke, almost all the negatives are easily dis-proven falsehoods. The knee-jerk zealots on Slashdot are too arrogant to educate themselves about this language unfortunately.
7. The ruby community is full of over-hyping zelous twits
You know, I wrote my post as a joke, to hopefully prevent stupid comments like yours. That yours was modded (twice) up is proof of the juvenile partisanship present here on slashdot.
Ruby and/or Rails sucks because:
1. It doesn't scale (Twitter)
2. It's slow
3. I read somewhere that Python was a better language
4. I write PHP, I can do everything Ruby/Rails can do better
5. My obnoxious younger coworker uses it
6. It's not lightweight enough
7. The ruby community is full of over-hyping zelous twits Ruby and/or Rails is awesome because:
1. It scales within reason (Twitter, Lighthouse, Shopify)
2. It's as fast as Python and PHP
3. I read somewhere it was better than Python
4. I used to write PHP, Ruby's been a godsend
5. There are so many motivated and innovative people in the community
6. It's featureful
7. Pythonistas are over-hyping jealous twits
That doesn't really carry much weight. In fact, from what I've seen, those that have migrated to Ruby from Python have largely migrated back - viewing Ruby as an interesting experiment
The plural of anecdote is not data.
While I don't have direct experience, Jython is very mature.... I suspect, Jython is as mature as JRuby.
Wow, I'd love to hear your opinion about things you have no experience with and have strong suspicious about.
How do you expect to be seriously talking about stuff you claim to not really know about?
I suspect you could benefit by taking a step back, re-reading your post, and spending some time reflecting on your own biases.
I love rdiff backup but I'd never use it on any large datasets. I attempted to use it on ~ 600 GB of data once with about 20GB of additions every month and it ran dog slow. As in taking 6+ hours to run every day (there were a lot of small files, dunno if that was the killer).
For larger datasets, like what the poster has, I'd go with a more comprehensive backup system, like bacula. I use that to backup about 12TB and it's rock solid and fast. There's a bit of a learning curve, but the documentation is very good.
If Bacula is too intimidating rsnapshot would be a viable route, it's similar to rdiff-backup, but simpler (pretty much just rsync + cp using hard links), faster, and easier to use. It's not as space efficient, but diffing video data is probably a waste of time anyway.
I'm pretty sure I saw the clip you were talking about. There were 2 guys with guns at the rally, one white, one black. During the newscast something got messed up, the reporter was talking about the white guy while pre-recorded footage of the black guy was playing. The reporter pointed this out while this happened, admitting to the screw up. I don't think anything intentionally disingenuous was going on, just a garden variety fuckup.
That's funny, because my single blade, double edged Merkur Heavy Duty has blades that cost ~50 cents (for top quality blades) and it shaves better than the fusion I used to use.
Those Fusion refills are ridiculously priced, at lots of markets they put em behind locked glass. That said, the fusion shaves better than a 2 bladed cartridge razor, and there's no learning curve.
I've run it on windows in FF and had issues as well, even with Java installed. Of course some of my DRACs are fairly old, but even the DRAC5s have been problematic for me. Maybe I need to update the firmware, an operation which, surprise, doesn't work right on ubuntu (Dell really only supports RHEL and their firmware upgrades sometimes refuse to work on ubuntu).
Ah yes, Dell Remote Access Controllers have a shitty as hell web interface that only seems to work in IE. I think it's supposed to work in firefox but it never has for me.
I read somewhere that's because Flash video decodes to RGB while X likes YUV video, so flash video can't use XV. If you try playing any video without XV it'll be slow and stutter.
That said, for some reason flash video plays much better on my nvidia card at work than my ati card at home.
The idea: use androgen ablation or hormone therapy to ignite an immune approach â" a pilot light â" and then, after a short interval of hormone therapy, introduce an anti-CTLA-4 antibody that acts like gasoline to this pilot light and overwhelms the cancer cells.
Fry: Usually on the show, they came up with a complicated plan, then explained it with a simple analogy. Leela: Hmmm... If we can re-route engine power through the primary weapons and configure them to Melllvar's frequency, that should overload his electro-quantum structure. Bender: Like putting too much air in a balloon! Fry: Of course! It's all so simple!
I know most of these comments aren't too serious, but oddly enough his experience with notes is part of why couch has turned out so well.
His experience with notes is pretty relevant as notes and couchdb are both document oriented databases. CouchDB is VERY different than notes in a lot of ways, Damien designed Couch with a lot of the problems of notes in mind. So, you can think of his time with notes as time he spent learning what not to do.
IBM funds CouchDB development through Apache paying Damien. They initially wanted him to work for IBM as a regular employee he told them he was unwilling to work in that corporate structure, leading to the current compromise.
Well you misunderstand scalability. Scalable DOES mean you can just throw more hardware at something, as you said. But you omit the part the scalability has limits. There's always a bottleneck, so no app is infinitely scalable. You take your best guess at what its intended audience will be and you proceed form there.
You can say my app's been designed so that it will scale when n is between 1 and 100,000 for instance. Or that it'll scale between 1 and 100,000,000,000,000. But the app you design for the later will be very different internally and take a lot more time to design. Most apps start out working only for small n because most apps will never get to big n or if they do, they do so gradually and give developers time to deal with it. Twitter was cursed by its own success, they didn't know it'd be as popular as it turned out.
Let's look at some specific technical details.
For most sites a single master DB server with slaves for reads is fine. Most apps out there don't need multi-master capabilities and thus implementing that would be a waste of time. In fact, most web apps you see out there are designed to run on a single DB server for reads and writes.
When Twitter started that's what they had and it worked. Then twitter got unexpectedly popular, and at that point in time Rails did not support multiple DB connections per instance, so sharding wasn't really possible. Days after they announced this problem it was fixed so it's no longer an issue.
We could speculate on problems they've had since then, but that would just be speculation. They've said repeatedly however that their stack's scalability issues have been in the non-rails parts (like the DB). Since they're the only ones who actually know what's going on, I'm inclined to believe them.
Let's look at some other social app failures,
An example would be myspace, which had horrible problems scaling, even though that was written in PHP which you consider to be super scalable. Or we could look at friendster, which was written in enterprisey java, which also had huge scaling problems. It's not the tool, it's how you use it.
Additionally, when you scale real world systems you just may find out the bottlenecks aren't where you thought they'd be during the design and testing. Runaway successes like twitter are vulnerable to this fact.
If you want to fault the Twitter engineers you really can only fault them for bad judgement in estimating the size of their user base. I don't think you know what Rails actually is. It's just helpers for YOUR code. Ultimately, a rails site is mostly your code, and your architecture.
Your ad nauseum argument says nothing, but since some moronic people with mod points are out there I may as well respond.
You haven't said anything specific about rails. There's tons of successful rails deployments out there, just because twitter's engineers suck at what they do doesn't mean the tech they use is bad. Tell me WHY does rails suck? What part of it is causing all these problems?
Also, Twitter isn't just rails, from all accounts the problems they have are from other parts of their stack. Again, not the tech used there, but their inability to deploy and set it up properly.
Also, If you've ever read about the architecture of Facebook you'd realize it's an extremely complex application. It's not just a simple LAMP stack, there's all kinds of caching and queing, with large hadoop clusters etc. Facebook is a HARD PROBLEM with a complicated solution. Luckily for facebook, they engineered it correctly. Those same tools if used improperly would not work.
Furthermore, your assertion that the data is easy is wrong. EVERYTHING IS EASY FOR SMALL N. The problem isn't the content, it's the quantity of messages. You may as well have said a man who eats 1000000000 jelly beans did something far easier than a man who ate a large burrito.
In short, don't hate the tool, hate the guy who's not using it right. Also, if you're going to critique something, be knowledgable and specific about it, don't just say X sucks because it sucks. Your ad nauseum argument says nothing.
Ummmm except that they handle a lot of little tidbits of text. Twitter isn't some chintzy simple site, they handle a HUGE volume of data. Their scalability problems come from their database layer (or rather their inability to setup a stable database layer) not Rails.
I'm punching the next person who posts to this that it doesn't scale because of rails in the face. I'm sick of people who don't understand the HUGE distinction between scalability and performance.
I get 950 Mbps with iperf (w/o jumbo frames). Actual disk to disk, or even disk to memory transfer speeds are at 30MB/s. If you'd read the article I linked to you'd know that.
Actual protocols are a LOT slower than just slamming as many bits as possible through a pipe.
Slashdot Mirror
Agreed, I track the CentOS and Ubuntu security lists to know when to reboot my services, and chances vulnerabilities for various libraries are much more common than other stuff. That said, a lot of the time you can get away with just restarting a service or two.
I'd put this service in the category of things that'd be nice to have, I'd consider paying $4/mo for it. Of course, if you really 'need' this service what you probably actually need is a hot spare with automatic failover.
Eeesh, what a tragedy. I got the same BS at my job, luckily my higher up was fired and I replaced him, letting me turn our crapload of PHP into Rails.
I took a good long look at the PHP MVC world when it was clear my company wasn't going to drink the Rails kool aid, and I have to say, none of the PHP frameworks were (at the time, 2 years ago) up to snuff compared to Rails. They were just flat out missing a lot of the features that made Rails great.
Plus, it takes me way less time to code in Ruby than PHP, PHP just takes more LoC, especially as your app's complexity increases.
Hey, I agree, I wrote that post as a joke, almost all the negatives are easily dis-proven falsehoods. The knee-jerk zealots on Slashdot are too arrogant to educate themselves about this language unfortunately.
7. The ruby community is full of over-hyping zelous twits
You know, I wrote my post as a joke, to hopefully prevent stupid comments like yours. That yours was modded (twice) up is proof of the juvenile partisanship present here on slashdot.
Well, if you want good, cheap rails hosting you could easily do Dreamhost or Heroku. I'd go with Heroku, they'll scale up pretty well.
Please pick form the list below
Ruby and/or Rails sucks because:
1. It doesn't scale (Twitter)
2. It's slow
3. I read somewhere that Python was a better language
4. I write PHP, I can do everything Ruby/Rails can do better
5. My obnoxious younger coworker uses it
6. It's not lightweight enough
7. The ruby community is full of over-hyping zelous twits
Ruby and/or Rails is awesome because:
1. It scales within reason (Twitter, Lighthouse, Shopify)
2. It's as fast as Python and PHP
3. I read somewhere it was better than Python
4. I used to write PHP, Ruby's been a godsend
5. There are so many motivated and innovative people in the community
6. It's featureful
7. Pythonistas are over-hyping jealous twits
That doesn't really carry much weight. In fact, from what I've seen, those that have migrated to Ruby from Python have largely migrated back - viewing Ruby as an interesting experiment
The plural of anecdote is not data.
While I don't have direct experience, Jython is very mature. ... I suspect, Jython is as mature as JRuby.
Wow, I'd love to hear your opinion about things you have no experience with and have strong suspicious about.
How do you expect to be seriously talking about stuff you claim to not really know about?
I suspect you could benefit by taking a step back, re-reading your post, and spending some time reflecting on your own biases.
I had no idea Rick Ross went after the CoS when not rapping.
I, like many of you here was wondering what the hell this could possibly be useful for, up until I viewed the video.
The answer, clearly, is porn.
It all makes sense now!
I love rdiff backup but I'd never use it on any large datasets. I attempted to use it on ~ 600 GB of data once with about 20GB of additions every month and it ran dog slow. As in taking 6+ hours to run every day (there were a lot of small files, dunno if that was the killer).
For larger datasets, like what the poster has, I'd go with a more comprehensive backup system, like bacula. I use that to backup about 12TB and it's rock solid and fast. There's a bit of a learning curve, but the documentation is very good.
If Bacula is too intimidating rsnapshot would be a viable route, it's similar to rdiff-backup, but simpler (pretty much just rsync + cp using hard links), faster, and easier to use. It's not as space efficient, but diffing video data is probably a waste of time anyway.
I'm pretty sure I saw the clip you were talking about. There were 2 guys with guns at the rally, one white, one black. During the newscast something got messed up, the reporter was talking about the white guy while pre-recorded footage of the black guy was playing. The reporter pointed this out while this happened, admitting to the screw up. I don't think anything intentionally disingenuous was going on, just a garden variety fuckup.
That's funny, because my single blade, double edged Merkur Heavy Duty has blades that cost ~50 cents (for top quality blades) and it shaves better than the fusion I used to use.
Those Fusion refills are ridiculously priced, at lots of markets they put em behind locked glass. That said, the fusion shaves better than a 2 bladed cartridge razor, and there's no learning curve.
I've run it on windows in FF and had issues as well, even with Java installed. Of course some of my DRACs are fairly old, but even the DRAC5s have been problematic for me. Maybe I need to update the firmware, an operation which, surprise, doesn't work right on ubuntu (Dell really only supports RHEL and their firmware upgrades sometimes refuse to work on ubuntu).
Ah yes, Dell Remote Access Controllers have a shitty as hell web interface that only seems to work in IE. I think it's supposed to work in firefox but it never has for me.
I read somewhere that's because Flash video decodes to RGB while X likes YUV video, so flash video can't use XV. If you try playing any video without XV it'll be slow and stutter.
That said, for some reason flash video plays much better on my nvidia card at work than my ati card at home.
Fry: Usually on the show, they came up with a complicated plan, then explained it with a simple analogy.
Leela: Hmmm... If we can re-route engine power through the primary weapons and configure them to Melllvar's frequency, that should overload his electro-quantum structure.
Bender: Like putting too much air in a balloon!
Fry: Of course! It's all so simple!
The reason this is stupid is because none of those things really have anything to do with a computer.
The reason this is offensive is because it shows how dell thought women were too stupid to recognize this.
Ummmmm, every ideology has a subset of people who behave this way.
Saying stuff like this helpfully labels you as being the kind of rabid fundamentalist you're accusing your opponents of being.
I know most of these comments aren't too serious, but oddly enough his experience with notes is part of why couch has turned out so well.
His experience with notes is pretty relevant as notes and couchdb are both document oriented databases. CouchDB is VERY different than notes in a lot of ways, Damien designed Couch with a lot of the problems of notes in mind. So, you can think of his time with notes as time he spent learning what not to do.
IBM funds CouchDB development through Apache paying Damien. They initially wanted him to work for IBM as a regular employee he told them he was unwilling to work in that corporate structure, leading to the current compromise.
Damien Katz, CouchDB's creator, worked at MySQL prior to writing CouchDB, and worked on Lotus Notes prior to that...
You've got a point, to an extent, I didn't make a list of successful rails deployments. Let's fix that with a list of successful rails apps:
http://rubyonrails.org/applications
Well you misunderstand scalability. Scalable DOES mean you can just throw more hardware at something, as you said. But you omit the part the scalability has limits. There's always a bottleneck, so no app is infinitely scalable. You take your best guess at what its intended audience will be and you proceed form there.
You can say my app's been designed so that it will scale when n is between 1 and 100,000 for instance. Or that it'll scale between 1 and 100,000,000,000,000. But the app you design for the later will be very different internally and take a lot more time to design. Most apps start out working only for small n because most apps will never get to big n or if they do, they do so gradually and give developers time to deal with it. Twitter was cursed by its own success, they didn't know it'd be as popular as it turned out.
Let's look at some specific technical details.
For most sites a single master DB server with slaves for reads is fine. Most apps out there don't need multi-master capabilities and thus implementing that would be a waste of time. In fact, most web apps you see out there are designed to run on a single DB server for reads and writes.
When Twitter started that's what they had and it worked. Then twitter got unexpectedly popular, and at that point in time Rails did not support multiple DB connections per instance, so sharding wasn't really possible. Days after they announced this problem it was fixed so it's no longer an issue.
We could speculate on problems they've had since then, but that would just be speculation. They've said repeatedly however that their stack's scalability issues have been in the non-rails parts (like the DB). Since they're the only ones who actually know what's going on, I'm inclined to believe them.
Let's look at some other social app failures,
An example would be myspace, which had horrible problems scaling, even though that was written in PHP which you consider to be super scalable. Or we could look at friendster, which was written in enterprisey java, which also had huge scaling problems. It's not the tool, it's how you use it.
Additionally, when you scale real world systems you just may find out the bottlenecks aren't where you thought they'd be during the design and testing. Runaway successes like twitter are vulnerable to this fact.
If you want to fault the Twitter engineers you really can only fault them for bad judgement in estimating the size of their user base. I don't think you know what Rails actually is. It's just helpers for YOUR code. Ultimately, a rails site is mostly your code, and your architecture.
Your ad nauseum argument says nothing, but since some moronic people with mod points are out there I may as well respond.
You haven't said anything specific about rails. There's tons of successful rails deployments out there, just because twitter's engineers suck at what they do doesn't mean the tech they use is bad. Tell me WHY does rails suck? What part of it is causing all these problems?
Also, Twitter isn't just rails, from all accounts the problems they have are from other parts of their stack. Again, not the tech used there, but their inability to deploy and set it up properly.
Also, If you've ever read about the architecture of Facebook you'd realize it's an extremely complex application. It's not just a simple LAMP stack, there's all kinds of caching and queing, with large hadoop clusters etc. Facebook is a HARD PROBLEM with a complicated solution. Luckily for facebook, they engineered it correctly. Those same tools if used improperly would not work.
Furthermore, your assertion that the data is easy is wrong. EVERYTHING IS EASY FOR SMALL N. The problem isn't the content, it's the quantity of messages. You may as well have said a man who eats 1000000000 jelly beans did something far easier than a man who ate a large burrito.
In short, don't hate the tool, hate the guy who's not using it right. Also, if you're going to critique something, be knowledgable and specific about it, don't just say X sucks because it sucks. Your ad nauseum argument says nothing.
Ummmm except that they handle a lot of little tidbits of text. Twitter isn't some chintzy simple site, they handle a HUGE volume of data. Their scalability problems come from their database layer (or rather their inability to setup a stable database layer) not Rails.
I'm punching the next person who posts to this that it doesn't scale because of rails in the face. I'm sick of people who don't understand the HUGE distinction between scalability and performance.
I get 950 Mbps with iperf (w/o jumbo frames). Actual disk to disk, or even disk to memory transfer speeds are at 30MB/s. If you'd read the article I linked to you'd know that.
Actual protocols are a LOT slower than just slamming as many bits as possible through a pipe.