I'm totally in agreement with your justifications. I have some similar ones. I get blockbuster and netflix since I don't have a tv either. One out of every 10 dvds or so just refuses to play in a pc dvd drive... so I download the same title. I already paid my movie fee, but got a bunk title due to some drm.
My point here, is that you have your reasons, I have mine, other people have theirs... and it's contributing to the global "moral justifications" of why copying is okay.
"Some circumstances" is a very broad term. I'm opposed to people who just download everything and never pay the creator but I can think of any number of circumstances where it's acceptable and even required.
But that's exactly my point!
According to the survey, the Some circumstances argument is what makes it morally justifiable to that segment of the population.
As far as the law goes... it's a ban on all circumstances other than what's defined in fair use. But in your case (and in others), in "some circumstances" it's okay to just download it because of [insert reason here].
where it's acceptable and even required.
What makes it acceptable? It's certainly against the law, so it's not the law that makes it acceptable. What else is it then? It's acceptable because it's morally acceptable.
I'm just stating the trends and observations that I've noticed over the past 20 years of computing. There's always been the crew that's cracked, copied, and distributed stuff (I remember playing pirated Apple2 games). Nowadays it's moving from the hidden away portion of society to mainstream where "everyone" is doing it. And since "everyone" is doing it, there seems to be a growing list of "some circumstances" in which make copying morally justifiable.
This thread has crystallized what I suspect is the "Slashdot-approved" stance with regards to protecting material. Correct me if I get any of these points wrong.
1. If you want to make a living creating works that exist in a data format (music, books, video) just accept the fact that nobody owes you a dime for your time. If some people choose to drop some money in your hat, that's awesome - but don't count on it.
I honestly don't think this is the case here. It's a case or morality and ease of action. The younger generations (myself included, I'm 27), are being taught by their peers, and sometimes their parents that copying music is okay. It's against the law.. but so is speeding (but that's another debate). With both speeding and music/movie/etc copying, it's a case of "The populous has spoken". Upon looking for some stats on the Wikipedia:
In 2004, an estimated 70 million people participated in online file sharing. According to a CBS News poll, nearly 70 percent of 18 to 29 year olds thought file sharing was acceptable in some circumstances and 58 percent of all Americans who followed the file sharing issue considered it acceptable in at least some circumstances. In July 2008, 20 percent of Europeans used file sharing networks to obtain music.
These are clearly not insignificant numbers, especially the current young adult generation. Seventy percent! That's the MAJORITY. We're clearly dealing with a global, quickly spreading phenomenon. Back when I was in high school (99-03), during my freshman year you needed to be in the "leet" crowd to know about file sharing, kids charged 5 bucks a cd to make you any album you wanted. By the time I was a senior no one was charging because everyone was just downloading. It was the dawn of the napster era.
Our culture is changing, and it's changing worldwide whether you like it or not. Computers are getting faster, bandwidth is getting more plentiful, and people are becoming more 'educated' on how to get things they want for free. They are also being taught that these ways of getting things for free are culturally and morally acceptable.
The majority of this culture (as you can see from Jason Brown's escapade) clearly isn't the "I don't owe you a dime for your work" crowd. Most of the traders that were contacted actually stopped the trading. Which seems to me that it's more of an "oh whoops, I didn't know you weren't cool with that" type of crowd.
2. If your music is so great, tour and make money that way. If you get moderately successful locally, each band member might be able to clear $80 a night! Of course you'll need a huge cash infusion (i.e. debt) to start touring big, but I'm sure the banks will be happy to help you with loans for such a riskless endeavour.
3. Always remember - costs like studio time, special effects, actors, musicians, props, sets, insurance, essentially every cost involved in the production of your work magically disconnect from the work itself at the moment it is finalized. A ripped copy of that work has absolutely no moral, legal, or implied connection to any of those costs.
For the most part, none of these items fit into the mindset of the culture involved in the sharing. How do I know? If these costs were considered, people would pony up for them. Our society as a whole is a compensation based society. People go to the supermarket for food. They pick out the food they want, then go to the register and pay. My inkling is that they pay because it costs money, time, and labor to produce these food items. But it's illegal to take the food without paying, so of course they pay right? Well it's also illegal to distribute copies of music. But, the thing is you don't see 70% of young adults shoplifting, because shoplifting is also morally and culturally wrong. What about the people who grow food at home for 'free'. They still have to buy or barter for seeds, which take time to collect and p
The thing I noticed first was that you can no longer drag the pages around in the html5 version.... they would need some more javascript. Is it just me... or is scribe showing just a bunch of jpegs as book pages? When you zoom in, you are zooming in on the original 640x480 jpeg and don't gain any benefit of getting more detail as you zoom in.
Well, the story has the assumption that the attacks are coming from EC2. If they are indeed coming from EC2, then amazon could find the source.
But if the source is outside of amazon, with spoofed source addresses of ec2 instances that have nothing to do with the attacks... then well... that's another issue.
My business debit card number (and my business partners number) were hijacked somewhere somehow. We've only used the cards at select merchants we've been dealing with for years, along with newegg, dell, and some local trusted shops.
My card is generally used for online purchases, and my partners card is generally used for offline purchases. Both card numbers were used in south africa to ring up 15,000 in charges in under 24 hours.
M&T Bank reversed every single last charge, but holey @(#&$!!! that was a ride.
I totally agree. I used a system where there was the following restrictions:
- Passwords must contain numbers and letters - You must have exactly one non-alpha-numeric character in the first three characters of your password - You must have exactly one number in the last three characters of your password - Your password must be between 8 and 12 characters - You must use a mixture of upper and lower case letters
So... that narrows the brute-force password attack down by a large factor. Either the rules were made by an idiot PHB or by a clueless IT person
They are advertised... I mean its in the name of the mobile plan - the Verizon mobile plans are called the 250/megs a month plan or 5 gigs a month plan or something like that.
Except the unlimited $29.99 data plan is advertised as... well... unlimited.
C integration with Groovy is the same as C integration with Java... since Groovy uses the JVM, which means making some definitions in Java for the external functions handled by C, adding some extra build options and writing the C module itself. It's the same as any other language... it's fairly easy to write C modules for tcl, perl, python. java, etc... you just need to look up the bindings library and off you go.
From my pov, it went from "did not know it existed" to "why is everyone so excited" pretty much over night. I don't get it and would appreciate it if anyone told me why this particular bit of hardware hit home so hardly.
Because when I was in EE classes in college it took weeks (probably faster for someone who knows what they were doing) to build up projects using ICs and little microcontrollers. The microcontrollers also had to be programmed with a UV eraser and reprogrammer, which required having a printout of the machine code in hex, and typing it all by hand into an eeprom programmer.
Now with the Adruino, you get a USB interface to a very cool little chip that you can upload C code on to. There's also bunches of modules (shields) that you can link together to create your project. Ethernet modules, wireless modules, input device modules, output device modules (led/lcd screens). All these boards can work together in harmony... versus building all this stuff from scratch with the basic components. They are also quite cheap compared to what it would cost to build from scratch.
Then you were basically working on a toy system processing very few transactions. In any system processing between mid to high volume, a SQL engine is serious overhead and should be accounted for in the design...
It was obvious. It is still obvious. Either the developers at your shop were blistering idiots for designing a solution for a problem that does not exist or you were the idiot for not understanding the software requirements.
Feisty aren't we?
What 'serious overhead' are you talking about anyway? The microseconds that it takes to parse a query and start the execution? It's always finding and fetching the data that's the most time consuming. But of course you already know that since you're apparently the expert.
No matter what system you're using, you still have to find and fetch the data... and what better tool to use than an SQL or equivalent database server?
At this point it's probably moot to argue, but I'll need to make some adjustments to your 'facts'.
I guess you've never actually worked with a large system, with millions of records, and thousands of transactions a day, used by some of the worlds largest collections agencies. It was such an annoying system to work with, so I hate to defend it, but it did do it's job well. It would be far from what anyone would consider to be a toy.
An SQL engine would have been perfect for the job at hand. Much more so than the inhouse datastore. And in fact we did use an SQL server for many of the reporting tools we had to write. It was a pleasure working on those projects. The problem of course is that the SQL part was a duct-taped on after-thought. Nightly syncs were done from the inhouse store to the SQL dbs so that the reports would be up to date. Despite 10's of millions of rows and hundreds of tables, the queries that were properly written, that used tables that were properly indexed, were lightning fast compared to the inhouse database.
The developers I worked with were far from idiots, myself included too of course. The crappy design stemmed from a lack of care from management, and a lack of systems training that should have been done before developers touched code for the first time after being hired. It's just one of those things that one needs to put up with in a corporate environment. Things are the way they are, and if you're not in a management position... well... tough luck. You do your tasks the best you can and go home.
That type of atmosphere breeds copy and paste programming, lack of formal design, and results in a crappy system.
Needless to say, I don't work there anymore.
I did find out after leaving that sometime later, there was a major re-architecture movement to a multi-tier platform with an oracle backend.
Network database storage has network latency, SQL parsing, and storage overhead. Local database storage has SQL parsing and storage overhead. Local binary data storage is very fast and minimal. I'm a bit surprised you would ask what gives. It's pretty obvious.
Actually, if you had worked on the system, you would be as annoyed/confused as I was. Query parsing has such low overhead compared to the time it took to do everything possible to not increase the size of structs. It also has a much lower overhead in terms of comparing it to the time it takes to manually write code to do left/right/inner/outer joins, subqueries and the like by hand. Linear lookups became so slow that covering indexes were shoved on some of the fields by hand. But since it was by hand... programs that weren't upgraded to use the new indexes, were still slow.
As time went on, they were developing: a high-maintenance, minimal feature, error prone... database system! Wow, that's so much more optimal than buying Ingres.
We avoided increasing the size of structs not for speed reasons... each struct was approaching half a meg already, so who cares. We avoided adding to them because it involved writing upgrade programs, and running said upgrades on hundreds of customer systems manually.
Some structs were usually padded quite nicely. Most had an extra kilobyte or two of padding. Some didn't. Some had 5 bytes free, and we would do crap like compression via bit twiddling to make use of as little extra space as possible. Not for speed, but to avoid upgrades.
Network latency, storage overhead and parse time would have been gladly accepted by all the devs in order to reduce the horrid nightmare of maintenance issues. But there were no plans by the phbs to overhaul the system.
There's something in programming called refactoring. When the maintenance on your app becomes more expensive than writing a new app... it's time to start planning a rewrite. But you generally don't want to even let it get that far. Ideally you refactor as you go, so that maintenance never gets even near that point.
Sure, in the 80's storage was expensive, computers were slow. In the 90's storage got cheaper, computers got faster.. But there was that same code, same raw structs... same loops copy and pasted across the system.
You should really think about the possible situation at hand before stating how something is 'pretty obvious'.
40k lines is itty bitty. Try working on a 25 year old legacy finance system with 1.5 million lines of C code, *most* of which is complete copy and paste from other parts of the system. The mantra was: "Need a new module... just copy that one, make your changes and commit". It's always fun fixing the same bug in 15 different spots.
And talk about diabolical... the "database" consisted of arrays of structs written directly to disk. Upgrades of data structures meant hours of importing the old data, copying it into a new struct that was bigger, and writing it back out. SQL databases were available in the 80''s... what gives?
A good programmer can take a 40k line system and make it mostly understood, documented, and unit tested in roughly 6-8 months (assuming there's no other work to be done). After that painful period, the coder's life will be much easier.
What leads you to believe that both of those projects are forks of MySQL? I'm not familiar with either one, but from the little poking I've done... they seem to have nothing to do with MySQL/
Pardon my naivete, but couldn't this be an opportunity for some other company to step in and fill the gap left behind by Oracle?
Sure. Any time there is a lapse in development from the big companies, the little ones have plenty of room to step in. But accessibility is not a huge market and it makes the most sense for one of the big companies to push it out as a loss-leader for community benefit.
Instead of putting a band-aid on the current architecture
But that's exactly how you run a successful system.
1) Design product to meet needs of your audience 2) Design the implementation that you think will handle the load the best (with lots of load testing and simulations to make sure it meets expected demand) 3) Build product 4) Watch it behave in the wild... Realize that actual demand is considerably higher than expected demand and will continue to grow 5) Performance slows with more users... you need a solution that will the push the date of catastrophic overload further into the future, to buy time to work on *really* fixing the problem 6) Migrate to a new or adjusted architecture that will solve this current problem 7) Go to step 4
Facebook is on phase 5. You sound like scripting languages are the bane of slow products. Yet in reality, the main bottleneck is generally the database. If facebook rewrote everything in C or some other non-scripting language, not only would it be an incredibly long process, but the the end result would be far less beneficial than if they revamped their existing technologies and worked to up database performance. There is no ultimate solution for scaling a product. You need to be constantly adjusting your strategies, implementations, and systems to cope with resource usage.
Slashdot Mirror
Nothing else crashes... just firefox
You missed: ::grumble grumble:: Crashy
Beta 4 crashes any time I right click on a link
It crashes any time I load a new plugin
It crashes any time I open a new tab
I'm totally in agreement with your justifications. I have some similar ones. I get blockbuster and netflix since I don't have a tv either. One out of every 10 dvds or so just refuses to play in a pc dvd drive... so I download the same title. I already paid my movie fee, but got a bunk title due to some drm.
My point here, is that you have your reasons, I have mine, other people have theirs... and it's contributing to the global "moral justifications" of why copying is okay.
"Some circumstances" is a very broad term. I'm opposed to people who just download everything and never pay the creator but I can think of any number of circumstances where it's acceptable and even required.
But that's exactly my point!
According to the survey, the Some circumstances argument is what makes it morally justifiable to that segment of the population.
As far as the law goes... it's a ban on all circumstances other than what's defined in fair use. But in your case (and in others), in "some circumstances" it's okay to just download it because of [insert reason here].
where it's acceptable and even required.
What makes it acceptable? It's certainly against the law, so it's not the law that makes it acceptable. What else is it then? It's acceptable because it's morally acceptable.
I'm just stating the trends and observations that I've noticed over the past 20 years of computing. There's always been the crew that's cracked, copied, and distributed stuff (I remember playing pirated Apple2 games). Nowadays it's moving from the hidden away portion of society to mainstream where "everyone" is doing it. And since "everyone" is doing it, there seems to be a growing list of "some circumstances" in which make copying morally justifiable.
This thread has crystallized what I suspect is the "Slashdot-approved" stance with regards to protecting material. Correct me if I get any of these points wrong.
1. If you want to make a living creating works that exist in a data format (music, books, video) just accept the fact that nobody owes you a dime for your time. If some people choose to drop some money in your hat, that's awesome - but don't count on it.
I honestly don't think this is the case here. It's a case or morality and ease of action. The younger generations (myself included, I'm 27), are being taught by their peers, and sometimes their parents that copying music is okay. It's against the law.. but so is speeding (but that's another debate). With both speeding and music/movie/etc copying, it's a case of "The populous has spoken". Upon looking for some stats on the Wikipedia:
These are clearly not insignificant numbers, especially the current young adult generation. Seventy percent! That's the MAJORITY. We're clearly dealing with a global, quickly spreading phenomenon. Back when I was in high school (99-03), during my freshman year you needed to be in the "leet" crowd to know about file sharing, kids charged 5 bucks a cd to make you any album you wanted. By the time I was a senior no one was charging because everyone was just downloading. It was the dawn of the napster era.
Our culture is changing, and it's changing worldwide whether you like it or not. Computers are getting faster, bandwidth is getting more plentiful, and people are becoming more 'educated' on how to get things they want for free. They are also being taught that these ways of getting things for free are culturally and morally acceptable.
The majority of this culture (as you can see from Jason Brown's escapade) clearly isn't the "I don't owe you a dime for your work" crowd. Most of the traders that were contacted actually stopped the trading. Which seems to me that it's more of an "oh whoops, I didn't know you weren't cool with that" type of crowd.
2. If your music is so great, tour and make money that way. If you get moderately successful locally, each band member might be able to clear $80 a night! Of course you'll need a huge cash infusion (i.e. debt) to start touring big, but I'm sure the banks will be happy to help you with loans for such a riskless endeavour.
3. Always remember - costs like studio time, special effects, actors, musicians, props, sets, insurance, essentially every cost involved in the production of your work magically disconnect from the work itself at the moment it is finalized. A ripped copy of that work has absolutely no moral, legal, or implied connection to any of those costs.
For the most part, none of these items fit into the mindset of the culture involved in the sharing. How do I know? If these costs were considered, people would pony up for them. Our society as a whole is a compensation based society. People go to the supermarket for food. They pick out the food they want, then go to the register and pay. My inkling is that they pay because it costs money, time, and labor to produce these food items. But it's illegal to take the food without paying, so of course they pay right? Well it's also illegal to distribute copies of music. But, the thing is you don't see 70% of young adults shoplifting, because shoplifting is also morally and culturally wrong. What about the people who grow food at home for 'free'. They still have to buy or barter for seeds, which take time to collect and p
Is there going to be a huge market for antivirus software for cell phones within the next few years?
You mean like duke nukem forever ?
The thing I noticed first was that you can no longer drag the pages around in the html5 version.... they would need some more javascript. Is it just me... or is scribe showing just a bunch of jpegs as book pages? When you zoom in, you are zooming in on the original 640x480 jpeg and don't gain any benefit of getting more detail as you zoom in.
Well, the story has the assumption that the attacks are coming from EC2. If they are indeed coming from EC2, then amazon could find the source.
But if the source is outside of amazon, with spoofed source addresses of ec2 instances that have nothing to do with the attacks... then well... that's another issue.
If the addresses are indeed spoofed, amazon could monitor their own network for packets leaving with the spoofed IP address.
You would think it would be pretty easily for Amazon to find and shut down the attackers... why haven't they done so already?
My business debit card number (and my business partners number) were hijacked somewhere somehow. We've only used the cards at select merchants we've been dealing with for years, along with newegg, dell, and some local trusted shops.
My card is generally used for online purchases, and my partners card is generally used for offline purchases. Both card numbers were used in south africa to ring up 15,000 in charges in under 24 hours.
M&T Bank reversed every single last charge, but holey @(#&$!!! that was a ride.
Check your bank balances OFTEN
I totally agree. I used a system where there was the following restrictions:
- Passwords must contain numbers and letters
- You must have exactly one non-alpha-numeric character in the first three characters of your password
- You must have exactly one number in the last three characters of your password
- Your password must be between 8 and 12 characters
- You must use a mixture of upper and lower case letters
So... that narrows the brute-force password attack down by a large factor. Either the rules were made by an idiot PHB or by a clueless IT person
They are advertised... I mean its in the name of the mobile plan - the Verizon mobile plans are called the 250/megs a month plan or 5 gigs a month plan or something like that.
Except the unlimited $29.99 data plan is advertised as... well... unlimited.
A while ago I worked on a java/c app, and it really wasn't that bad to integrate with the jvm and pass data around. It's a matter of reading the docs.
C integration with Groovy is the same as C integration with Java... since Groovy uses the JVM, which means making some definitions in Java for the external functions handled by C, adding some extra build options and writing the C module itself. It's the same as any other language... it's fairly easy to write C modules for tcl, perl, python. java, etc... you just need to look up the bindings library and off you go.
especially since the pc piracy rate is around 80-90%
[Citation needed]
There's three types of lies:... Lies, Damned Lies, and Statistics.
From my pov, it went from "did not know it existed" to "why is everyone so excited" pretty much over night. I don't get it and would appreciate it if anyone told me why this particular bit of hardware hit home so hardly.
Because when I was in EE classes in college it took weeks (probably faster for someone who knows what they were doing) to build up projects using ICs and little microcontrollers. The microcontrollers also had to be programmed with a UV eraser and reprogrammer, which required having a printout of the machine code in hex, and typing it all by hand into an eeprom programmer.
Now with the Adruino, you get a USB interface to a very cool little chip that you can upload C code on to. There's also bunches of modules (shields) that you can link together to create your project. Ethernet modules, wireless modules, input device modules, output device modules (led/lcd screens). All these boards can work together in harmony... versus building all this stuff from scratch with the basic components. They are also quite cheap compared to what it would cost to build from scratch.
Then you were basically working on a toy system processing very few transactions. In any system processing between mid to high volume, a SQL engine is serious overhead and should be accounted for in the design...
It was obvious. It is still obvious. Either the developers at your shop were blistering idiots for designing a solution for a problem that does not exist or you were the idiot for not understanding the software requirements.
Feisty aren't we?
What 'serious overhead' are you talking about anyway? The microseconds that it takes to parse a query and start the execution? It's always finding and fetching the data that's the most time consuming. But of course you already know that since you're apparently the expert.
No matter what system you're using, you still have to find and fetch the data... and what better tool to use than an SQL or equivalent database server?
At this point it's probably moot to argue, but I'll need to make some adjustments to your 'facts'.
I guess you've never actually worked with a large system, with millions of records, and thousands of transactions a day, used by some of the worlds largest collections agencies. It was such an annoying system to work with, so I hate to defend it, but it did do it's job well. It would be far from what anyone would consider to be a toy.
An SQL engine would have been perfect for the job at hand. Much more so than the inhouse datastore. And in fact we did use an SQL server for many of the reporting tools we had to write. It was a pleasure working on those projects. The problem of course is that the SQL part was a duct-taped on after-thought. Nightly syncs were done from the inhouse store to the SQL dbs so that the reports would be up to date. Despite 10's of millions of rows and hundreds of tables, the queries that were properly written, that used tables that were properly indexed, were lightning fast compared to the inhouse database.
The developers I worked with were far from idiots, myself included too of course. The crappy design stemmed from a lack of care from management, and a lack of systems training that should have been done before developers touched code for the first time after being hired. It's just one of those things that one needs to put up with in a corporate environment. Things are the way they are, and if you're not in a management position... well... tough luck. You do your tasks the best you can and go home.
That type of atmosphere breeds copy and paste programming, lack of formal design, and results in a crappy system.
Needless to say, I don't work there anymore.
I did find out after leaving that sometime later, there was a major re-architecture movement to a multi-tier platform with an oracle backend.
Network database storage has network latency, SQL parsing, and storage overhead. Local database storage has SQL parsing and storage overhead. Local binary data storage is very fast and minimal. I'm a bit surprised you would ask what gives. It's pretty obvious.
Actually, if you had worked on the system, you would be as annoyed/confused as I was. Query parsing has such low overhead compared to the time it took to do everything possible to not increase the size of structs. It also has a much lower overhead in terms of comparing it to the time it takes to manually write code to do left/right/inner/outer joins, subqueries and the like by hand. Linear lookups became so slow that covering indexes were shoved on some of the fields by hand. But since it was by hand... programs that weren't upgraded to use the new indexes, were still slow.
As time went on, they were developing: a high-maintenance, minimal feature, error prone... database system! Wow, that's so much more optimal than buying Ingres.
We avoided increasing the size of structs not for speed reasons... each struct was approaching half a meg already, so who cares. We avoided adding to them because it involved writing upgrade programs, and running said upgrades on hundreds of customer systems manually.
Some structs were usually padded quite nicely. Most had an extra kilobyte or two of padding. Some didn't. Some had 5 bytes free, and we would do crap like compression via bit twiddling to make use of as little extra space as possible. Not for speed, but to avoid upgrades.
Network latency, storage overhead and parse time would have been gladly accepted by all the devs in order to reduce the horrid nightmare of maintenance issues. But there were no plans by the phbs to overhaul the system.
There's something in programming called refactoring. When the maintenance on your app becomes more expensive than writing a new app... it's time to start planning a rewrite. But you generally don't want to even let it get that far. Ideally you refactor as you go, so that maintenance never gets even near that point.
Sure, in the 80's storage was expensive, computers were slow. In the 90's storage got cheaper, computers got faster.. But there was that same code, same raw structs... same loops copy and pasted across the system.
You should really think about the possible situation at hand before stating how something is 'pretty obvious'.
40k lines is itty bitty. Try working on a 25 year old legacy finance system with 1.5 million lines of C code, *most* of which is complete copy and paste from other parts of the system. The mantra was: "Need a new module... just copy that one, make your changes and commit". It's always fun fixing the same bug in 15 different spots.
And talk about diabolical... the "database" consisted of arrays of structs written directly to disk. Upgrades of data structures meant hours of importing the old data, copying it into a new struct that was bigger, and writing it back out. SQL databases were available in the 80''s... what gives?
A good programmer can take a 40k line system and make it mostly understood, documented, and unit tested in roughly 6-8 months (assuming there's no other work to be done). After that painful period, the coder's life will be much easier.
Arg... Haha... Apparently I missed this on the drizzle site:
"The code is originally derived from MySQL."
But I don't see such mention on the planetmariadb site.
What leads you to believe that both of those projects are forks of MySQL? I'm not familiar with either one, but from the little poking I've done... they seem to have nothing to do with MySQL/
Pardon my naivete, but couldn't this be an opportunity for some other company to step in and fill the gap left behind by Oracle?
Sure. Any time there is a lapse in development from the big companies, the little ones have plenty of room to step in. But accessibility is not a huge market and it makes the most sense for one of the big companies to push it out as a loss-leader for community benefit.
Instead of putting a band-aid on the current architecture
But that's exactly how you run a successful system.
1) Design product to meet needs of your audience
2) Design the implementation that you think will handle the load the best (with lots of load testing and simulations to make sure it meets expected demand)
3) Build product
4) Watch it behave in the wild... Realize that actual demand is considerably higher than expected demand and will continue to grow
5) Performance slows with more users... you need a solution that will the push the date of catastrophic overload further into the future, to buy time to work on *really* fixing the problem
6) Migrate to a new or adjusted architecture that will solve this current problem
7) Go to step 4
Facebook is on phase 5. You sound like scripting languages are the bane of slow products. Yet in reality, the main bottleneck is generally the database. If facebook rewrote everything in C or some other non-scripting language, not only would it be an incredibly long process, but the the end result would be far less beneficial than if they revamped their existing technologies and worked to up database performance. There is no ultimate solution for scaling a product. You need to be constantly adjusting your strategies, implementations, and systems to cope with resource usage.