It's an obvious false dilemma that quality news and profits cannot coexist. People who want to destroy private industry always make the claim that profit undermines quality, as if consumers don't want quality. That simply isn't true. Before someone comes in and talks about the 'stupid consumer', the trade off between price and quality varies greatly up and down the scale for every product, including news. Your anecdotal experience with some stupid people you know is not evidence that every consumer doesn't know what's best for them or the things they want.
This totally misses the point, as most of slashdot does. His company relies on their credibility to get them by. A security company without credibility is the most worthless thing ever.
Last time he found an exploit he reported it publicly and to apple and what did apple do? They claimed the exploit never existed and threatened to sue him over it. Now 50% of slashdotters think he was lying about the exploit just to get some PR. That's not the kind of PR he wants and he knew that would be the kind he'd get if he was in fact lying, so his incentive to lie doesn't exist, his incentive to be credible and correct is very high. But the result of that episode was that every no-talent asshat who knows nothing about whether or not the exploit actually existed or what it entailed just believed apple's PR department, seriously tarnishing his reputation in the process. Certainly every person who might be buying his software will believe apple's PR.
This isn't a "he was mean to me, I'll be mean to him" decision, he doesn't want to go through that shit again and hurt his business and reputation even worse. Whether or not apple *actually* works to fix the bugs is irrelevant, all that matters is how they act publicly because that is what affects his business and his day to day life.
Apple basically punished him for doing the right thing. I can't blame him for not doing it again.
Fair Use covers much more than personal use, it covers all usage which is fair. Book, papers, DJs, etc. all make use of the fair use doctrine clause on a daily basis for commercial gain. An example can be found in a talk given by Lessig on the fair use of the google book search project here: http://www.lessig.org/blog/archives/003292.shtml.
Re:Rails needs to be more mature
on
Ruby For Rails
·
· Score: 1
This is not a question of maturity for rails and more a question of design. You will never see things like this happen in rails for the entire life of the core product. Data persistence logic like this is a responsibility delegated to the the model of the data and not the database.
I'm pretty sure that responding to requests over the HTTP protocol and being able to easily access databases is here to stay. Rails can send out any data it wants meaning that it's simply the easiest of the MVC web application frameworks. I'm pretty sure web applications are here to stay for quite some time. That is all.
Decaf this is the same thing you say on every rails thread.
Rails is an 80% solution. Screw portability it is not a serious problem to most people. I don't know any companies who are switching database vendors more than once every 4 or 5 years, and when they do it's because they are writing a new application. This is the real world, who cares? We already have many tools written in ruby for consuming and modifying data from outside services and they work just fine in rails.
This is not a "problem", this is a restriction by design. Rails is designed to do one thing only and one thing well. Respond to HTTP requests by serving data which is persisted into a database. This is how it was designed and this is how it is advertised. If the design and purpose changes later then we can debate the merits of pluggable persistence layers and portability.
Introspection is not some magical black box that needs to be controlled and contained. Databases have the functionality so that applications can use it. Why on earth would I want to create my entire schema in the database and then redo it in some other language or format when the database provides the services to know information about it already? Seems a little wasteful to me.
I don't work for these guys so these opinions are merely my own.
You guys just read the summary and everytime is says AJAX you automatically start bashing the company using it. AJAX is a tool for allowing a smoother, more interactive, and more responsive interface on the web. AJAX simply makes it a little better than hitting a button and waiting to see if the screen will refresh. If you guys write software and you don't agree that user interfaces should be responsive and informative then I pity your your users. Who the hell labeled AJAX as a buzzword, it's an acronym. I don't want to say 'asynchronous javascript and xml' everytime I want to describe my usage of a set of a few technologies working in tandem, just like you don't want to when you describe the large set of technologies you use in your everyday job. Without acronyms our writing and speech would become long winded, muddled, and confusing. So please stop the hatred of acronyms, they never hated you for anything.
Secondly, real administrators do use control panels and/or scripts to do things you need to do. As a real administrator your tasks everyday simple encompass too many areas of responsibility to spend 10 hours a day setting up features for hosting accounts. A control panel can speed this up as it provides a centralized interface to access a lot of common functionality. The argument against this is similar to an argument for just using flat files that accounting will go look through for information instead of using a database and some application that accesses it, that would be lunacy.
Thirdly, I'll gladly take an interface that isn't slow, obnoxiously ugly and difficult to use. Webmin, CPanel, Ensim, they are all deep, complex, and ugly. Webmin is the worst. The benefit of the webfaction control panel is not that it can do what other control panels can't already do, I mean if that were ever the argument for any progress we'd still be using C for all our applications since it does everything in a very portable way. The benefit is that it provides a simple easy to use interface for setting up and configuring web applications, source control repositories, as well as hosting features like email, databases, and user accounts. It does this is a straightforward way that doesn't confuse the issue. This increases the speed with which you are able to add and modify these features.
The other thing it does is treat all of those other applications and frameworks as if they were like PHP. Meaning that if more hosting companies had a similar panel that some of these applications and frameworks would become ubiquitous like PHP is. This company is just trying to make money while pushing forward the adoption of good new open source technologies, which is more than almost any of you could say about yourselves. On slashdot of all places how could this be seen as a bad thing?
Slashdot really has turned into something else altogether.
That being said, you shouldn't post about your own company on slashdot.
I suppose that it can be true that wages rise faster than inflation in one particular area, in the short term. Inflation does not always imply a decrease in purchasing power. However, in the long term increases in standard of living and purchasing power are realized by increases in production efficiency. By being able to increase the quantity produced by utilizing the same amount of capital or labor real prices will decrease and more goods will be available to the market.
More generally when employment and/or wages increase so does the price inflation in that market. India is a country that is already beginning to experience this, even if it's just in certain sectors it will eventually spread to all parts of that economy.
The fact is that your comment a few posts ago about "they'll make their money in the short term" is in fact fine. Because who defines how long terms are? Any company making any money in any period is fine. It means more wealth, more products, more emploment, etc. The companies don't just take it and stuff it under a pillow, it gets spent somewhere else. Who cares if they move to 50 countries with 50 new industries. It just means cheaper products for you and I and a growing economy for you and I, and the rest of the world. This isn't a zero sum game, wealth is being created throughout the world by teaching other countries to use their resources to educate their people, create technologies, and use their comparative advantage in certain industries to make everyone happier.
This is for everyone else not you:
Someone would innevitably bust in here about how I wouldn't say that if I had lost my job to an Indian or something. Guess what, I have lost jobs to people. Big deal. There is no magic doctrine that says I get to do what I want when I want because I'm better than someone else and am more deserving. You get another job. You work at McDonalds if you have to. You do whatever it takes. If it hurts your pride and it's hard to feed your kids and yourself and they foreclose on your house and you have to live in public housing, then you do it until you can make it better. It's competition and everyone can't be on top. But throughout time more people will be better off because of it than are worse off.
No hard feelings then..:) This is/. where people who have things to say get frustrated most of the time from people who don't have things to say. I withdraw my troll comment..
The problem with words is that they're always vague until you define them. I mean if I told you about groups in mathematics it would be vague until I defined it. So would all things. I think the difference between buzzwords and undefined words is a fine point missed by most slashdotters. Which is really odd coming from a community where acronyms and abbreviations are the norm. For example, to distill several paragraphs about how wikipedia works down into one word like co-creation isn't to somehow make it a buzzword, it's only trying to assign labels to ideas so that we can use them in everday speach without having to restate the entire workings of wikipedia. It also presents a slightly more abstract term that allows us to apply the idea to other sites which are not wikipedia. This helps gain more understanding of what it really is that makes wikis so special and how to make other sites that could benefit from the ideas wikis use.
The problem in marketing is that they are assigning labels to things that developers don't think need labels. Some of the time this is to differentiate themselves in the marketplace when they aren't different at all. This is what bothers developers and engineers, probably beccause one of the things they want to do most is make something original and new.
About portals and remixability. This hasn't happened yet, but imagine a world full of google maps like services. Where most services become syndicated for a small fee, or for advertising. People can then build up their own services that are mixtures of services from other companies. It would be like yahoo opening up all of their different communities (mail, dating, etc.) and giving everyone an open API to use it in a certain way. Then dating sites could use the yahoo personals service to mix up new services. Perhaps by adding metadata that was relevant to their users only, filtering results of personals, and giving them an interface that is more comfortable to their age/gender/whatever. Then they could add in google mail through an API as their account/login system, and then whatever other kinds of services through an API. This is the kind of service remixability that I'm talking about. Making sites where most things are based on services.
This is a major step forward not because no one has done anything like this, but because of the number of people the web has using it now. It becomes less important to hold prime properties on the internet (like yahoo, google, etc.) and more important to simply run the services that have control of the most/best information and tools. If the web continues on the track of services then the people who create successful web businesses in the future will be the ones who find innovative ways to gather, store, license, and interface with information that people will want to access as services and not necessarily websites. You already see google, yahoo, and microsoft moving in directions like these through experimentation with APIs.
If you want to say something useful just say it. The way it usually works is you paste a quote of something I said in my post and then you argue either for it or against it and you support yourself with examples and/or reasoning. There are several other paragraphs and even articles linked for you to work with. Just filling you on how things normally work. Except on slashdot apparently.
No I just assumed the words would be commonplace amongst the slashdot crowd. Co-creation is obviously a popular attribute due to the success of the wiki. Not just co-creation by employees or affiliates, creation by everyone. Remixability refers to services like google maps which allow users to drop things ontop of them to create entirely new services, not just clones of the ones they are using. Decentralization is often manifested in the use of RSS/Atom feeds, and blogs since the trackback system and engines like Technorati allow publishing to be dispersed amongst a more disparate group of contacts instead of a central publishing agency. The network effect is just a term for some of the mathematical results of research in different types of networks including small world networks and other non-linear phenomena. The network effect is the most imortant part of the whole thing since the web has passed critical mass: http://en.wikipedia.org/wiki/Network_effect for more.
But now that I look at what your list says, and my list says, they are the same thing.
Lots more people comfortable using the web (Network Effect)
Tools that let them just type stuff and post pictures (even video!) without knowing crap about HTML (Co-creation)
Tools that interact with other tools (RSS feeds and the like) (Decentralization)
Specialized portals acting as services (Allows remixability)
So if by
Did you use that random business marketspeak generator to create your post?
You mean identified and gave definitive terms to what you only vaguely tried to speak about, then yes, whatever you say. Otherwise, I tried to enlighten the people reading this thread who think that all the fuss is about some random web technology like AJAX, so stop trolling.
By the way most of the definitive web 2.0 style companies like 37signals, 9rules, etc. use massive fonts to make things easier to read, go check out some of their web applications.
It would be typical with a forum full of engineers to simply pass up web 2.0 as some marketing buzzword for a new implementation of something old. In many ways the attributes associated with what is being collectively called 'web 2.0' are simply old ideas implemented in a medium where they can succeed in a big way.
It's important to understand that the difference in the web is not in the implementation but in the experience of the end user and how content is created, managed, and distributed. Adaptive path has a writeup about this at http://adaptivepath.com/publications/essays/archiv es/000547.php
The difference is important because it changes how developers and designers percieve the web when they are creating new things. There are many features of newer web software that contribute to the ways in which people use and experience the web.
My favorite is the preference in designing software for the long tail. Which is mentioned in Wired
http://www.wired.com/wired/archive/12.10/tail.html
This is the practice of serving many niche markets with targeted software instead of building software to service all of the market and doing it badly. This causes less confusion, less clutter, better software and faster turnaround.
Some of the other features of the newer web software you might have already noticed are decentralization, remixability, co-creation, and their side-effect of emergent systems. Web services, niche software and the network effect all make these things much more feasible than they have been in the past since there are well defined frameworks for distributing services that are easy to work with and adding more niche services increases the value of all web software by a large amount.
Notice I didn't say AJAX or Ruby on Rails or Django or [insert your new framework or technology here]. These are merely details of implementation. If a framework makes your company faster then that's good. If a technology lets your user's client fetch web service data for them, that can also be good. These things are only technologies used to reach an end product. Web 2.0 could have been done in many languages and frameworks and on many platforms. That's not to say that certain languages, frameworks, etc. didn't have an effect on the design of the software, as any language or framework has a certain effect on the overall style of the developers using it.
This was about a need for developers and designers to move beyond what was status quo for interaction between websites and their users. They are taking full advantage of the tools they have created and the network that was built up over the past few decades. To belittle their efforts into something meaningless is to surely miss the entire point.
What 'witchcraft spells' are you talking about? As far as I can tell web development is simply an application of several standard technologies such as http, html, css, and ecma-232./confused
For example, you may have test datasets that don't need constraints as you are the only one using them. But, for the real deployment (which may be a multi-user and multi-app environment) you get the constraints for free that protect your data.
So what you're saying is that the ORM layer groks the foreign keys from the object models and places the constraints on the database when it is available as a feature. This is not bad, but once again, you can't rely on those keys for data validation in your application unless you know that all of your development/deployment systems have this ability.
No, it doesn't. It can use highly specific optimisations (types of joins, specific functions available in specific database products etc.) to produce very highly tuned queries.
We must be living in very different worlds.. Go read your logs show me this magic SQL and the joins you're talking about and the functions as well.. I'll believe that they exist when I see them.. I've been developing web applications for a long time; I must have missed out on all this special tech.
they don't hide the fact that your data model simply doesn't exist away from the database
You're right, the domain model resides inside the database. That is its purpose and the reason it is relational. Maybe this is a difference of philosophy.
No, you are wrong. You don't have to pick a set of features with a Java ORM - you get the full set of features for the database you deploy on automatically.
If you define in your model that you have foreign keys but you deploy to sqlite, you don't have foreign keys. That is a trade off for any application in any framework. Therefore if sqlite is your deployment database your application has to decide that you can't rely on features not implemented in sqlite. This is what I meant. These are decisions made when the application is planned.
If you're saying that you will just define the maximum set of features and then the database tool will skip the ones that aren't available in one database when deploying to it, and will use them on deployment to another database, then fine. But that is simply a waste of your time.
The only way you could ever have an application that relies on sophisticated database features in a deployment environment is to also have those features available for you in your testing and development environment. In any event during development if you're developing on a database with lesser features than your deployment environment, you can't test those features in your application. If you're developing on the database with more features than your deployment environment you can't implement the features in your application since you don't have the database to support them in your development setup.
Also, what features are we even talking about? The only possible feature I could think of is foriegn keys and user defined data types since that is something that can be represented in a model. Everything else an ORM does is select, update, insert, and delete in very standard ways. All of these other 'features' like views, triggers, stored procedures, indices, caching etc. are indepedent of the queries or frameworks that you use and are carried out by the database and not implemented in any model objects. I know for a fact ORMs like Hibernate simply write normal SQL queries even if they have to translate them from special query languages like HQL. All of the special options that you put in hibernate models merely tell it how to form the SQL and which other models to join or save when performing different operations.
such as the inability to test parts of the code away from the database.
We use functional, unit, and integration tests with fixtures.
you aren't the only only user of the database, and such relationships have to be put and kept in the database.
Why does you not being the only user of the database mean that foreign key constraints have to be kept in the database? Foreign keys don't somehow make your colleagues better developers..:)
Sorry, you are flat wrong about this. Quality Java ORM systems will automatically make use of the full features of specific databases in order to provide optimum efficiency in querying - as a developer you don't have to put work in to get this. If you have a complex object query, vendor-specific features will be used to make that query work fast. However, if you port exactly the same object query code to another database, it will use different vendor features automatically.
As indicated above, you are wrong. There are ORMs that are far more mature and capable than Rails, and that will automatically go beyond SQL-99 and use powerful features of specific databases to get performance.
What are these vendor specific features that you're referring to that speed up the queries an ORM is doing? I'd like to hear about at least one or two.
Most quality Java ORMs have features to generate object models from databases.
The way I work is to develop my object model in one place only - Java classes. The ORM will automatically generate foreign keys in whatever database I choose when it generates the schema to represent my classes.
So which is it? Are we generating models from databases or databases from models?
In the case that we're generating databases from the object model, as you prefer, you still have to list out everything explicitly in your models to generate your databases in which case rails does not do this as it is designed to have the database be created first. Once again the java ORM can't generate foriegn keys in sqlite or other databases that don't support them. This has the possibility of leaving your database schema inconsistent between database vendors and if you were relying on foriegn keys for any type of data validation then your entire application is going to be inconsistent. The solution is simple, don't rely on foreign keys. Relying on foreign keys actually places you closer to your database implementation and not further away from it, which you argued earlier is what you don't want. Also use of foreign keys doesn't allow for rich features like polymorphic associations.
The same argument can be made for all features that are not standard across database vendors. If database portability is a major concern for the application then you have to pick the set of features for some set of databases that you want your application to be portable across and only use features from those databases. Like I said, java has made this tradeoff, but it has only worried about db2, sql server, and oracle. The intersection of the features of these database vendors is where most java ORMs choose to set their feature base lower limit. If you added some other databases and versions in there you'd lose foriegn keys and several other features. Rails adds in MySql, postgres and sqlite which makes the intersection of features smaller. Is this the right place to place the level of support in the framework or the wrong place? I don't know.
In the case where you make your database first and then generate your object models, well then rails is much better at this than any java ORM mainly because of the strong run-time reflection that ruby allows.
No, these problem aren't solved. Look at the schema migration documentation. There are significant things that aren't migrated - 'minor' things like foreign keys!
I'll admit you can't define foriegn keys natively in your migrations. There are design decisions for this, mainly due the syntax differences and support for foriegn keys amongst databases vendors. They might add them later they might not. Rails prefers to keep this information at the ruby level right now using the has_many, belongs_to, etc. modifiers in the models.
Why?
I have SQL, I don't need EQL or any other specialized language. I work with my objects natively in ruby and don't even worry about SQL since ActiveRecord takes care of writing it for me. Don't you? All I have to do to change which database I'm using is change the database user/pass/name in a config file and rerun my migrations on the new database to generate the new schema. I still don't get foreign keys generated in the new databases which is GREAT if I'm using sqlite2 since it doesn't support foreigns keys. What does java do? Probably just ignores that sqlite2 even exists.
This is false in almost every respect. Standard SQL is not and has never been portable - migrations between, say SQL Server and DB2 are a nightmare in terms of SQL. Some small subset may be roughly portable, but if you use this subset, you aren't using the full power of the databse.
SQL-99 has been supported by all database vendors for years. If you are using the 'full power' features that are available in one database that aren't available in another no amount of magic database tools are going to make the features available. Not to mention even some features like 'views' or 'triggers' that several vendors support will have different implementations and different sql syntax. So the question is where do you draw the line with the features you expect to be portable amongst all of your database implementations and where should your database tools draw the line? For rails the line is drawn at sqlite which has a very small feature set compared to other databases. Does java even write things like views for you? This would seem a bit over the top and unecessary.
Also we're talkign about two different pieces here, Migrations and the ORM. The only thing that is not included in the ORM is automatically forming object relations from foriegn keys without having to explicity tell the model about it. But you can't do that in java either, you have to tell the models about their foriegn key relationships even when they are specified in the database already. Other than that the ORM (ActiveRecord) writes the same standard SQL-99 for select, update, delete, insert, count, etc. as any ORM would write from its models in java or otherwise; nothing special is required at this layer. Migrations are relatively new so the ability to store views, triggers, etc. in the ruby schema file is not included and even if it was, should it be? I don't particularly think it should, since this would ruin the database agnosticity of migrations. For instance you couldn't migrate views or triggers to sqlite no matter how sophisticated your database tools were.
Basecamp uses Ruby on Rails. They serve over 1.8 million hits a month. They use caching and lighttpd with fastcgi. But you can do the same with apache/fastcgi or whatever webserver you want with fastcgi or SCGI. If you don't design your database schema and web application code with scalability and performance in mind then it will be difficult to scale up to a large number of users.
Things to consider include:
Web server
Use of a web server like lighttpd, zeus, or litespeed which use non-blocking select-based connection handling instead of a pre-forking method like apache can handle several times more traffic on the same machine and with less memory and processor usage. This means more performance for your applications.
Usage of on disk sessions
Database storage for session data is much faster and allows for easy http load balancing when the application grows large enough to warrant it.
Number of database queries
Designing the database so that the number of required queries is small. This might require the use of 'eager loading' which performs table joins to form larger result sets with more data. This leads to fewer queries that are larger in size.
Size of each result set
Queries that return a large number of fields or rows can cause a problem because the ORM has to map the result set to objects which means a lot of allocations and assignments by the interpreter. Many times you can solve this by providing paging for large datasets, and additionaly by using the 'lazy loading' behavior of most ORMs so that data is loaded only at the time it is needed. This leads to more queries that are smaller in size.
Database indexing
A lot of the bottlenecks of busy web applications are caused by the database. An intelligent use of indexing can cause select statements to run a orders of magnitude faster than they would otherwise. However, each time you insert a new row or update an indexed field in a table the index has to be recreated for that portion so you have to index appropriately. This is one of the most important things you can do improve the performance of your web applications.
Disk Caching
Cache controllers, actions, models, or blocks of code that render/fetch data so that it can be pulled straight from disk. This can speed up applications by immense factors. For instance in a blog the pages don't need to change unless someone adds a new comment or a post. Caching all of the blog pages until someone adds a comment or a post speeds up the application by a large amount since most of the requests are read-only.
Memory Caching
Add-ons like memcache allow your cache to be stored directly into memory, making it even faster.
That being said, all of these things are supported in rails. If you want to make web applications with ruby on rails or any other framework fly, these are the things to consider. If you do these things your rails application will perform as well as almost any other framework around, even at high load times.
What is this talk about tight coupling and databases? The ORM in rails is not database vendor specific. I don't know a single framework that enforces a database vendor. I'm really confused about what you're talking about. In order to change database vendors in rails you change the database type in one config file and the database adapter automatically changes. The SQL generated by ActiveRecord is standard and the messaging and protocols to the database are specific to the adapters included in rails.
If your schema changes you just change your models if that is even necessary since you don't have to define any of the field names in your models by default so it is highly likely they will just work. If that fails you can always use database migrations which allow you to not only represent your schema in ruby but also to version your database. This works very well with a version control system.
No one should be making drastic changes to some centralized production schema that isn't somehow recorded in a version control patch that can be checked out and run to update your local development/testing database schema. Then you can test your web application code against the new database schema before submitting changes to the repository.
Actually all of these database problems are solved by Migration in ruby on rails. Not only do they allow you a database agnostic representation of your database schema defined purely in ruby (for sql server, mysql, sqlite, db2, oracle, postgres). They also give you schema versioning capabilities that tie into your deployment tasks if you're using switchtower.
I also find the idea of having to write my queries in a specialized 'portable' query language pretty annoying. If you use standard SQL it is portable anyhow and adding one more level of indirection so I can do the same thing is, not too bright. But with migrations you don't have to worry about any of that anyway.
Ruby, by design, takes less lines to do the same thing than most statically typed languages mainly because of its heavy usage of lexical closures. Closures are implemented as what people see as 'blocks' in ruby, which allows code to be more meaningful and terse.
If you read the paragraphs directly below that you will see that the circle is indeed not necessary and serves no utility other than to mark the differences between the classic definition and his definition. The definition of spread is actually inherently different than that of angle and has separate properties. The reason it might look the same is that it is analogous although not equivalent to the definition of angle. After all, classical trigonometry is correct..:)
The 8 billion dollars won't matter when that companies top execs are thrown into jail for the rest of their life for killing someone or being purposefully fraudulent to their customers. If you could steal and kill all day long and then just go to court with great lawyers to make a buck right now you might; that's what corporations can do because of their government shielding. If the executives and stockholders are held accountable for the companies actions, not only would all of the executives focus on the bottom line, but they would focus on how to NOT break the laws. Of course there must be laws as such, so that total liberatarianism wouldn't work too well, but definitely a moderate form could work.
The value I was talking about was in the increasing technology not necessarily in the quality control procedures. I'm not going to argue that quality control in America is still pretty bad compared to the purely mathematical and analytical methods of some of the Asian manufacturing countries. By the way complexity does not equal quality. While your easy to fix engine might be a novel idea most of your old stock small block 8's produce less horsepower and torque than newer 6's and they certainly use more gas. There isn't any arguing that technology is better now than it was then. You have to think about this technology improvement when you look at the overall price/income layout now and then. You're not buying the same product then as you are now so you have to be careful when you make a direct comparison.
Meanwhile I have been thinking a bit more about the impact of credit on the consumer and commercial markets. Economics would say something like this. If the bank has $100 to loan out then they'll loan out $90 of it to someone, who will then spend or loan out a portion of that money. This process will continue until some limit is met. This process is called multiple expansion and the overall effect is to inflate the money supply and the banks end up owning everything. Instead of the money being in the banks and/or savings it is being circulated to many different people which causes a lot of increased spending. This causes certain longer-term markets to bear higher priced goods because people will take out a few thousand extra on their already large loan to pay a slightly larger amount. Unfortunately this happens over and over again for decades and you get the overpriced car and housing markets that require 60 month and 30 year loans respectively. That is, even the people that wouldn't have used credit are forced to buy in this market, therefore expanding the use of credit even more. Paying it back is the bad part, and a lot of people get into trouble here. That's all I will say about that.
I thought a bit more about your social security comment. Social security is based purely on population. The account isn't shrinking, it's just not going to be funded for the baby boomers because there are a lot more of them. It's a simple distribution of birth rate.
Go read the statistics on small businesses and you'll see that wealth is NOT distributed to the wealth 1%.
It's the small businesses, the average guy that makes up most of the united states. Small businesses don't outsource and they represent 99.7% of overall employment, a point that many people seem to miss. They seem to feel this overall big divide between everyone else and themselves mostly because of their frustrations about their own positions. There does not exist this great divide that everyone seems to want to talk about. Some people are rich, some people are poor. some people are in the middle. Almost 50% of private sector wages are paid to these 99.7% of the employees so you know they aren't rich. that means at LEAST 50% are middle of the road workers trying to feed their families. And I'd be willing to say quite a bit more. although I can only theorize about that.
As far as the free trade question. The total production and output of society has a few different quantities associated with it, I guess we'll look at the GDP. The GDP of India is low, a lot of the population is not educated and they are overcrowded and don't live in the best conditions. Now assume that someone jumped started a service sector for them, (Like IT). Now all of a sudden they need products, buildings, and personel to support their cause. They hire more people close to them. They also need services performed for them so that gets even more people on board. Now these people with jobs buy more things, the IT people buy more things and eventually they become more and more wealthy (with someone elses we
Slashdot Mirror
It's an obvious false dilemma that quality news and profits cannot coexist. People who want to destroy private industry always make the claim that profit undermines quality, as if consumers don't want quality. That simply isn't true. Before someone comes in and talks about the 'stupid consumer', the trade off between price and quality varies greatly up and down the scale for every product, including news. Your anecdotal experience with some stupid people you know is not evidence that every consumer doesn't know what's best for them or the things they want.
This totally misses the point, as most of slashdot does. His company relies on their credibility to get them by. A security company without credibility is the most worthless thing ever.
Last time he found an exploit he reported it publicly and to apple and what did apple do? They claimed the exploit never existed and threatened to sue him over it. Now 50% of slashdotters think he was lying about the exploit just to get some PR. That's not the kind of PR he wants and he knew that would be the kind he'd get if he was in fact lying, so his incentive to lie doesn't exist, his incentive to be credible and correct is very high. But the result of that episode was that every no-talent asshat who knows nothing about whether or not the exploit actually existed or what it entailed just believed apple's PR department, seriously tarnishing his reputation in the process. Certainly every person who might be buying his software will believe apple's PR.
This isn't a "he was mean to me, I'll be mean to him" decision, he doesn't want to go through that shit again and hurt his business and reputation even worse. Whether or not apple *actually* works to fix the bugs is irrelevant, all that matters is how they act publicly because that is what affects his business and his day to day life.
Apple basically punished him for doing the right thing. I can't blame him for not doing it again.
Fair Use covers much more than personal use, it covers all usage which is fair. Book, papers, DJs, etc. all make use of the fair use doctrine clause on a daily basis for commercial gain. An example can be found in a talk given by Lessig on the fair use of the google book search project here: http://www.lessig.org/blog/archives/003292.shtml.
This is not a question of maturity for rails and more a question of design. You will never see things like this happen in rails for the entire life of the core product. Data persistence logic like this is a responsibility delegated to the the model of the data and not the database.
I'm pretty sure that responding to requests over the HTTP protocol and being able to easily access databases is here to stay. Rails can send out any data it wants meaning that it's simply the easiest of the MVC web application frameworks. I'm pretty sure web applications are here to stay for quite some time. That is all.
Decaf this is the same thing you say on every rails thread. Rails is an 80% solution. Screw portability it is not a serious problem to most people. I don't know any companies who are switching database vendors more than once every 4 or 5 years, and when they do it's because they are writing a new application. This is the real world, who cares? We already have many tools written in ruby for consuming and modifying data from outside services and they work just fine in rails. This is not a "problem", this is a restriction by design. Rails is designed to do one thing only and one thing well. Respond to HTTP requests by serving data which is persisted into a database. This is how it was designed and this is how it is advertised. If the design and purpose changes later then we can debate the merits of pluggable persistence layers and portability. Introspection is not some magical black box that needs to be controlled and contained. Databases have the functionality so that applications can use it. Why on earth would I want to create my entire schema in the database and then redo it in some other language or format when the database provides the services to know information about it already? Seems a little wasteful to me.
I don't work for these guys so these opinions are merely my own.
You guys just read the summary and everytime is says AJAX you automatically start bashing the company using it. AJAX is a tool for allowing a smoother, more interactive, and more responsive interface on the web. AJAX simply makes it a little better than hitting a button and waiting to see if the screen will refresh. If you guys write software and you don't agree that user interfaces should be responsive and informative then I pity your your users. Who the hell labeled AJAX as a buzzword, it's an acronym. I don't want to say 'asynchronous javascript and xml' everytime I want to describe my usage of a set of a few technologies working in tandem, just like you don't want to when you describe the large set of technologies you use in your everyday job. Without acronyms our writing and speech would become long winded, muddled, and confusing. So please stop the hatred of acronyms, they never hated you for anything.
Secondly, real administrators do use control panels and/or scripts to do things you need to do. As a real administrator your tasks everyday simple encompass too many areas of responsibility to spend 10 hours a day setting up features for hosting accounts. A control panel can speed this up as it provides a centralized interface to access a lot of common functionality. The argument against this is similar to an argument for just using flat files that accounting will go look through for information instead of using a database and some application that accesses it, that would be lunacy.
Thirdly, I'll gladly take an interface that isn't slow, obnoxiously ugly and difficult to use. Webmin, CPanel, Ensim, they are all deep, complex, and ugly. Webmin is the worst. The benefit of the webfaction control panel is not that it can do what other control panels can't already do, I mean if that were ever the argument for any progress we'd still be using C for all our applications since it does everything in a very portable way. The benefit is that it provides a simple easy to use interface for setting up and configuring web applications, source control repositories, as well as hosting features like email, databases, and user accounts. It does this is a straightforward way that doesn't confuse the issue. This increases the speed with which you are able to add and modify these features.
The other thing it does is treat all of those other applications and frameworks as if they were like PHP. Meaning that if more hosting companies had a similar panel that some of these applications and frameworks would become ubiquitous like PHP is. This company is just trying to make money while pushing forward the adoption of good new open source technologies, which is more than almost any of you could say about yourselves. On slashdot of all places how could this be seen as a bad thing?
Slashdot really has turned into something else altogether.
That being said, you shouldn't post about your own company on slashdot.
I suppose that it can be true that wages rise faster than inflation in one particular area, in the short term. Inflation does not always imply a decrease in purchasing power. However, in the long term increases in standard of living and purchasing power are realized by increases in production efficiency. By being able to increase the quantity produced by utilizing the same amount of capital or labor real prices will decrease and more goods will be available to the market.
More generally when employment and/or wages increase so does the price inflation in that market. India is a country that is already beginning to experience this, even if it's just in certain sectors it will eventually spread to all parts of that economy.
The fact is that your comment a few posts ago about "they'll make their money in the short term" is in fact fine. Because who defines how long terms are? Any company making any money in any period is fine. It means more wealth, more products, more emploment, etc. The companies don't just take it and stuff it under a pillow, it gets spent somewhere else. Who cares if they move to 50 countries with 50 new industries. It just means cheaper products for you and I and a growing economy for you and I, and the rest of the world. This isn't a zero sum game, wealth is being created throughout the world by teaching other countries to use their resources to educate their people, create technologies, and use their comparative advantage in certain industries to make everyone happier.
This is for everyone else not you: Someone would innevitably bust in here about how I wouldn't say that if I had lost my job to an Indian or something. Guess what, I have lost jobs to people. Big deal. There is no magic doctrine that says I get to do what I want when I want because I'm better than someone else and am more deserving. You get another job. You work at McDonalds if you have to. You do whatever it takes. If it hurts your pride and it's hard to feed your kids and yourself and they foreclose on your house and you have to live in public housing, then you do it until you can make it better. It's competition and everyone can't be on top. But throughout time more people will be better off because of it than are worse off.
No hard feelings then..:) This is /. where people who have things to say get frustrated most of the time from people who don't have things to say. I withdraw my troll comment..
The problem with words is that they're always vague until you define them. I mean if I told you about groups in mathematics it would be vague until I defined it. So would all things. I think the difference between buzzwords and undefined words is a fine point missed by most slashdotters. Which is really odd coming from a community where acronyms and abbreviations are the norm. For example, to distill several paragraphs about how wikipedia works down into one word like co-creation isn't to somehow make it a buzzword, it's only trying to assign labels to ideas so that we can use them in everday speach without having to restate the entire workings of wikipedia. It also presents a slightly more abstract term that allows us to apply the idea to other sites which are not wikipedia. This helps gain more understanding of what it really is that makes wikis so special and how to make other sites that could benefit from the ideas wikis use.
The problem in marketing is that they are assigning labels to things that developers don't think need labels. Some of the time this is to differentiate themselves in the marketplace when they aren't different at all. This is what bothers developers and engineers, probably beccause one of the things they want to do most is make something original and new.
About portals and remixability. This hasn't happened yet, but imagine a world full of google maps like services. Where most services become syndicated for a small fee, or for advertising. People can then build up their own services that are mixtures of services from other companies. It would be like yahoo opening up all of their different communities (mail, dating, etc.) and giving everyone an open API to use it in a certain way. Then dating sites could use the yahoo personals service to mix up new services. Perhaps by adding metadata that was relevant to their users only, filtering results of personals, and giving them an interface that is more comfortable to their age/gender/whatever. Then they could add in google mail through an API as their account/login system, and then whatever other kinds of services through an API. This is the kind of service remixability that I'm talking about. Making sites where most things are based on services.
This is a major step forward not because no one has done anything like this, but because of the number of people the web has using it now. It becomes less important to hold prime properties on the internet (like yahoo, google, etc.) and more important to simply run the services that have control of the most/best information and tools. If the web continues on the track of services then the people who create successful web businesses in the future will be the ones who find innovative ways to gather, store, license, and interface with information that people will want to access as services and not necessarily websites. You already see google, yahoo, and microsoft moving in directions like these through experimentation with APIs.
Inflation of wages decreases purchasing power. Have you actually studied any economics?:)
If you want to say something useful just say it. The way it usually works is you paste a quote of something I said in my post and then you argue either for it or against it and you support yourself with examples and/or reasoning. There are several other paragraphs and even articles linked for you to work with. Just filling you on how things normally work. Except on slashdot apparently.
No I just assumed the words would be commonplace amongst the slashdot crowd. Co-creation is obviously a popular attribute due to the success of the wiki. Not just co-creation by employees or affiliates, creation by everyone. Remixability refers to services like google maps which allow users to drop things ontop of them to create entirely new services, not just clones of the ones they are using. Decentralization is often manifested in the use of RSS/Atom feeds, and blogs since the trackback system and engines like Technorati allow publishing to be dispersed amongst a more disparate group of contacts instead of a central publishing agency. The network effect is just a term for some of the mathematical results of research in different types of networks including small world networks and other non-linear phenomena. The network effect is the most imortant part of the whole thing since the web has passed critical mass: http://en.wikipedia.org/wiki/Network_effect for more.
But now that I look at what your list says, and my list says, they are the same thing.
So if by
You mean identified and gave definitive terms to what you only vaguely tried to speak about, then yes, whatever you say. Otherwise, I tried to enlighten the people reading this thread who think that all the fuss is about some random web technology like AJAX, so stop trolling.By the way most of the definitive web 2.0 style companies like 37signals, 9rules, etc. use massive fonts to make things easier to read, go check out some of their web applications.
It would be typical with a forum full of engineers to simply pass up web 2.0 as some marketing buzzword for a new implementation of something old. In many ways the attributes associated with what is being collectively called 'web 2.0' are simply old ideas implemented in a medium where they can succeed in a big way.
It's important to understand that the difference in the web is not in the implementation but in the experience of the end user and how content is created, managed, and distributed. Adaptive path has a writeup about this at http://adaptivepath.com/publications/essays/archiv es/000547.php
The difference is important because it changes how developers and designers percieve the web when they are creating new things. There are many features of newer web software that contribute to the ways in which people use and experience the web.
My favorite is the preference in designing software for the long tail. Which is mentioned in Wired http://www.wired.com/wired/archive/12.10/tail.html
This is the practice of serving many niche markets with targeted software instead of building software to service all of the market and doing it badly. This causes less confusion, less clutter, better software and faster turnaround.
Some of the other features of the newer web software you might have already noticed are decentralization, remixability, co-creation, and their side-effect of emergent systems. Web services, niche software and the network effect all make these things much more feasible than they have been in the past since there are well defined frameworks for distributing services that are easy to work with and adding more niche services increases the value of all web software by a large amount.
Notice I didn't say AJAX or Ruby on Rails or Django or [insert your new framework or technology here]. These are merely details of implementation. If a framework makes your company faster then that's good. If a technology lets your user's client fetch web service data for them, that can also be good. These things are only technologies used to reach an end product. Web 2.0 could have been done in many languages and frameworks and on many platforms. That's not to say that certain languages, frameworks, etc. didn't have an effect on the design of the software, as any language or framework has a certain effect on the overall style of the developers using it.
This was about a need for developers and designers to move beyond what was status quo for interaction between websites and their users. They are taking full advantage of the tools they have created and the network that was built up over the past few decades. To belittle their efforts into something meaningless is to surely miss the entire point.
What 'witchcraft spells' are you talking about? As far as I can tell web development is simply an application of several standard technologies such as http, html, css, and ecma-232. /confused
If only the standard of living was affected by wages. It's not.
E co no mics
So what you're saying is that the ORM layer groks the foreign keys from the object models and places the constraints on the database when it is available as a feature. This is not bad, but once again, you can't rely on those keys for data validation in your application unless you know that all of your development/deployment systems have this ability.
We must be living in very different worlds.. Go read your logs show me this magic SQL and the joins you're talking about and the functions as well.. I'll believe that they exist when I see them.. I've been developing web applications for a long time; I must have missed out on all this special tech.
You're right, the domain model resides inside the database. That is its purpose and the reason it is relational. Maybe this is a difference of philosophy.
If you define in your model that you have foreign keys but you deploy to sqlite, you don't have foreign keys. That is a trade off for any application in any framework. Therefore if sqlite is your deployment database your application has to decide that you can't rely on features not implemented in sqlite. This is what I meant. These are decisions made when the application is planned.
If you're saying that you will just define the maximum set of features and then the database tool will skip the ones that aren't available in one database when deploying to it, and will use them on deployment to another database, then fine. But that is simply a waste of your time.
The only way you could ever have an application that relies on sophisticated database features in a deployment environment is to also have those features available for you in your testing and development environment. In any event during development if you're developing on a database with lesser features than your deployment environment, you can't test those features in your application. If you're developing on the database with more features than your deployment environment you can't implement the features in your application since you don't have the database to support them in your development setup.
Also, what features are we even talking about? The only possible feature I could think of is foriegn keys and user defined data types since that is something that can be represented in a model. Everything else an ORM does is select, update, insert, and delete in very standard ways. All of these other 'features' like views, triggers, stored procedures, indices, caching etc. are indepedent of the queries or frameworks that you use and are carried out by the database and not implemented in any model objects. I know for a fact ORMs like Hibernate simply write normal SQL queries even if they have to translate them from special query languages like HQL. All of the special options that you put in hibernate models merely tell it how to form the SQL and which other models to join or save when performing different operations.
We use functional, unit, and integration tests with fixtures.
Why does you not being the only user of the database mean that foreign key constraints have to be kept in the database? Foreign keys don't somehow make your colleagues better developers..:)
What are these vendor specific features that you're referring to that speed up the queries an ORM is doing? I'd like to hear about at least one or two.
So which is it? Are we generating models from databases or databases from models?
In the case that we're generating databases from the object model, as you prefer, you still have to list out everything explicitly in your models to generate your databases in which case rails does not do this as it is designed to have the database be created first. Once again the java ORM can't generate foriegn keys in sqlite or other databases that don't support them. This has the possibility of leaving your database schema inconsistent between database vendors and if you were relying on foriegn keys for any type of data validation then your entire application is going to be inconsistent. The solution is simple, don't rely on foreign keys. Relying on foreign keys actually places you closer to your database implementation and not further away from it, which you argued earlier is what you don't want. Also use of foreign keys doesn't allow for rich features like polymorphic associations.
The same argument can be made for all features that are not standard across database vendors. If database portability is a major concern for the application then you have to pick the set of features for some set of databases that you want your application to be portable across and only use features from those databases. Like I said, java has made this tradeoff, but it has only worried about db2, sql server, and oracle. The intersection of the features of these database vendors is where most java ORMs choose to set their feature base lower limit. If you added some other databases and versions in there you'd lose foriegn keys and several other features. Rails adds in MySql, postgres and sqlite which makes the intersection of features smaller. Is this the right place to place the level of support in the framework or the wrong place? I don't know.
In the case where you make your database first and then generate your object models, well then rails is much better at this than any java ORM mainly because of the strong run-time reflection that ruby allows.
I'll admit you can't define foriegn keys natively in your migrations. There are design decisions for this, mainly due the syntax differences and support for foriegn keys amongst databases vendors. They might add them later they might not. Rails prefers to keep this information at the ruby level right now using the has_many, belongs_to, etc. modifiers in the models.
I have SQL, I don't need EQL or any other specialized language. I work with my objects natively in ruby and don't even worry about SQL since ActiveRecord takes care of writing it for me. Don't you? All I have to do to change which database I'm using is change the database user/pass/name in a config file and rerun my migrations on the new database to generate the new schema. I still don't get foreign keys generated in the new databases which is GREAT if I'm using sqlite2 since it doesn't support foreigns keys. What does java do? Probably just ignores that sqlite2 even exists.
SQL-99 has been supported by all database vendors for years. If you are using the 'full power' features that are available in one database that aren't available in another no amount of magic database tools are going to make the features available. Not to mention even some features like 'views' or 'triggers' that several vendors support will have different implementations and different sql syntax. So the question is where do you draw the line with the features you expect to be portable amongst all of your database implementations and where should your database tools draw the line? For rails the line is drawn at sqlite which has a very small feature set compared to other databases. Does java even write things like views for you? This would seem a bit over the top and unecessary.
Also we're talkign about two different pieces here, Migrations and the ORM. The only thing that is not included in the ORM is automatically forming object relations from foriegn keys without having to explicity tell the model about it. But you can't do that in java either, you have to tell the models about their foriegn key relationships even when they are specified in the database already. Other than that the ORM (ActiveRecord) writes the same standard SQL-99 for select, update, delete, insert, count, etc. as any ORM would write from its models in java or otherwise; nothing special is required at this layer. Migrations are relatively new so the ability to store views, triggers, etc. in the ruby schema file is not included and even if it was, should it be? I don't particularly think it should, since this would ruin the database agnosticity of migrations. For instance you couldn't migrate views or triggers to sqlite no matter how sophisticated your database tools were.
Basecamp uses Ruby on Rails. They serve over 1.8 million hits a month. They use caching and lighttpd with fastcgi. But you can do the same with apache/fastcgi or whatever webserver you want with fastcgi or SCGI. If you don't design your database schema and web application code with scalability and performance in mind then it will be difficult to scale up to a large number of users.
Things to consider include:
Web server
Use of a web server like lighttpd, zeus, or litespeed which use non-blocking select-based connection handling instead of a pre-forking method like apache can handle several times more traffic on the same machine and with less memory and processor usage. This means more performance for your applications.
Usage of on disk sessions
Database storage for session data is much faster and allows for easy http load balancing when the application grows large enough to warrant it.
Number of database queries
Designing the database so that the number of required queries is small. This might require the use of 'eager loading' which performs table joins to form larger result sets with more data. This leads to fewer queries that are larger in size.
Size of each result set
Queries that return a large number of fields or rows can cause a problem because the ORM has to map the result set to objects which means a lot of allocations and assignments by the interpreter. Many times you can solve this by providing paging for large datasets, and additionaly by using the 'lazy loading' behavior of most ORMs so that data is loaded only at the time it is needed. This leads to more queries that are smaller in size.
Database indexing
A lot of the bottlenecks of busy web applications are caused by the database. An intelligent use of indexing can cause select statements to run a orders of magnitude faster than they would otherwise. However, each time you insert a new row or update an indexed field in a table the index has to be recreated for that portion so you have to index appropriately. This is one of the most important things you can do improve the performance of your web applications.
Disk Caching
Cache controllers, actions, models, or blocks of code that render/fetch data so that it can be pulled straight from disk. This can speed up applications by immense factors. For instance in a blog the pages don't need to change unless someone adds a new comment or a post. Caching all of the blog pages until someone adds a comment or a post speeds up the application by a large amount since most of the requests are read-only.
Memory Caching
Add-ons like memcache allow your cache to be stored directly into memory, making it even faster.
That being said, all of these things are supported in rails. If you want to make web applications with ruby on rails or any other framework fly, these are the things to consider. If you do these things your rails application will perform as well as almost any other framework around, even at high load times.
What is this talk about tight coupling and databases? The ORM in rails is not database vendor specific. I don't know a single framework that enforces a database vendor. I'm really confused about what you're talking about. In order to change database vendors in rails you change the database type in one config file and the database adapter automatically changes. The SQL generated by ActiveRecord is standard and the messaging and protocols to the database are specific to the adapters included in rails.
If your schema changes you just change your models if that is even necessary since you don't have to define any of the field names in your models by default so it is highly likely they will just work. If that fails you can always use database migrations which allow you to not only represent your schema in ruby but also to version your database. This works very well with a version control system.
No one should be making drastic changes to some centralized production schema that isn't somehow recorded in a version control patch that can be checked out and run to update your local development/testing database schema. Then you can test your web application code against the new database schema before submitting changes to the repository.
Actually all of these database problems are solved by Migration in ruby on rails. Not only do they allow you a database agnostic representation of your database schema defined purely in ruby (for sql server, mysql, sqlite, db2, oracle, postgres). They also give you schema versioning capabilities that tie into your deployment tasks if you're using switchtower.
I also find the idea of having to write my queries in a specialized 'portable' query language pretty annoying. If you use standard SQL it is portable anyhow and adding one more level of indirection so I can do the same thing is, not too bright. But with migrations you don't have to worry about any of that anyway.
This is also pretty informative about web applications and frameworks
http://oodt.jpl.nasa.gov/better-web-app.mov
Ruby, by design, takes less lines to do the same thing than most statically typed languages mainly because of its heavy usage of lexical closures. Closures are implemented as what people see as 'blocks' in ruby, which allows code to be more meaningful and terse.
If you read the paragraphs directly below that you will see that the circle is indeed not necessary and serves no utility other than to mark the differences between the classic definition and his definition. The definition of spread is actually inherently different than that of angle and has separate properties. The reason it might look the same is that it is analogous although not equivalent to the definition of angle. After all, classical trigonometry is correct..:)
The 8 billion dollars won't matter when that companies top execs are thrown into jail for the rest of their life for killing someone or being purposefully fraudulent to their customers. If you could steal and kill all day long and then just go to court with great lawyers to make a buck right now you might; that's what corporations can do because of their government shielding. If the executives and stockholders are held accountable for the companies actions, not only would all of the executives focus on the bottom line, but they would focus on how to NOT break the laws. Of course there must be laws as such, so that total liberatarianism wouldn't work too well, but definitely a moderate form could work.
The value I was talking about was in the increasing technology not necessarily in the quality control procedures. I'm not going to argue that quality control in America is still pretty bad compared to the purely mathematical and analytical methods of some of the Asian manufacturing countries. By the way complexity does not equal quality. While your easy to fix engine might be a novel idea most of your old stock small block 8's produce less horsepower and torque than newer 6's and they certainly use more gas. There isn't any arguing that technology is better now than it was then. You have to think about this technology improvement when you look at the overall price/income layout now and then. You're not buying the same product then as you are now so you have to be careful when you make a direct comparison.
Meanwhile I have been thinking a bit more about the impact of credit on the consumer and commercial markets. Economics would say something like this. If the bank has $100 to loan out then they'll loan out $90 of it to someone, who will then spend or loan out a portion of that money. This process will continue until some limit is met. This process is called multiple expansion and the overall effect is to inflate the money supply and the banks end up owning everything. Instead of the money being in the banks and/or savings it is being circulated to many different people which causes a lot of increased spending. This causes certain longer-term markets to bear higher priced goods because people will take out a few thousand extra on their already large loan to pay a slightly larger amount. Unfortunately this happens over and over again for decades and you get the overpriced car and housing markets that require 60 month and 30 year loans respectively. That is, even the people that wouldn't have used credit are forced to buy in this market, therefore expanding the use of credit even more. Paying it back is the bad part, and a lot of people get into trouble here. That's all I will say about that.
I thought a bit more about your social security comment. Social security is based purely on population. The account isn't shrinking, it's just not going to be funded for the baby boomers because there are a lot more of them. It's a simple distribution of birth rate.
Go read the statistics on small businesses and you'll see that wealth is NOT distributed to the wealth 1%.
http://app1.sba.gov/faqs/faqIndexAll.cfm?areaid=24
It's the small businesses, the average guy that makes up most of the united states. Small businesses don't outsource and they represent 99.7% of overall employment, a point that many people seem to miss. They seem to feel this overall big divide between everyone else and themselves mostly because of their frustrations about their own positions. There does not exist this great divide that everyone seems to want to talk about. Some people are rich, some people are poor. some people are in the middle. Almost 50% of private sector wages are paid to these 99.7% of the employees so you know they aren't rich. that means at LEAST 50% are middle of the road workers trying to feed their families. And I'd be willing to say quite a bit more. although I can only theorize about that.
As far as the free trade question. The total production and output of society has a few different quantities associated with it, I guess we'll look at the GDP. The GDP of India is low, a lot of the population is not educated and they are overcrowded and don't live in the best conditions. Now assume that someone jumped started a service sector for them, (Like IT). Now all of a sudden they need products, buildings, and personel to support their cause. They hire more people close to them. They also need services performed for them so that gets even more people on board. Now these people with jobs buy more things, the IT people buy more things and eventually they become more and more wealthy (with someone elses we