In spite of the title, the article does not state 'Linux Five Years Away From Mainstream'. In states that 'Linux is five years away from mainstream use in Enterprise IT infrastructures. This is all about high-end data-centre stuff - a niche use. This article is confusing a very specialised use of Linux with it's general use as, for example, a mid-range server where it has proved it's successfulness for years. There is further confusion where the article mentions that 'many are re-evaluating Linux use' (many turns out to be 5 CIOs out of a panel of 12).
I don't know whether this article is deliberate FUD, or just a confused mess. I suspect the latter.
So there you have it, Natural Selection. It only allows through time, the good genes to pass, the genes that are responsible for allowing the creature to best co-exist in it's habitat.
No. It is far more complex that that. Evolution can be driven by things that have nothing at all to do with environment - look at things like the peacock's tain for example - something that is positively disadvantageous regarding environment. However, there are well-known selection mechanisms that allow even such 'bad' features to evolve - it is to do with competition within a species, not the environment.
Now, since we don't have a time machine, we CANNOT falsify historical evolution. It's just a theory, and absent a time machine we won't ever be able to test it.
Of course you can test it. You can make predictions about the way things could have evolved and what intermediate forms may have been present. You can then look for such forms in fossils. For example, there have been several theories about the lineage of whales, and fossil finds have helped test these theories.
In this sense evolution is a lot like cosmology. We can't go back to the early stages of the universe, but we can predict what should be there then look at distant (effectively 'fossil') light with telescopes.
Yes, smart people still trump over stupid people in most aspects of life, but stupid people still reproduce. Civilization has removed the engine through which drives the evolution of the species.
Not necessarily. Pressure for evolution does not have to be external - it can be driven by, for example, the preferences of members of a species about who they mate with. As long as women are selective about their male partners and men are the same then there will be evolution.
But because you are still in orbit, you are still under the influence of Earth's gravity.
Yes, but the gravity you experience is zero. If you are free-falling, even in a gravitional field, you don't feel any force (apart from very tiny tidal effects).
The idea is the users will have a chance to get use to OpenOffice, before they have to get use to linux.
Which quite honestly is a bigger change than changing from M$ Office to OpenOffice.
You and I may have no problem changing OS'es just like that, but they are dealing with general users that wont be, and will simply be expecting there computers to just work.
Having performed exactly this sort of migration, I completely disagree. It is the switch between Office systems that is the main issue. For a typical commercial user of workstations a Linux desktop can, if set up right, be immediately useable by anyone who has used a typical Windows desktop: icons for office applications, directory exploring, browser, e-mail etc. can made visible and then the user can get started - the computer 'just works'.
The big transition is in the way that the user will do various tasks in the office suite - multiple document management, mail merge etc.
Are you talking about legacy schemas, or tables designed for use with RoR?
This does include legacy and current schemas. The way most commercial (and government) database work is that you simply don't get to design the tables for just your app - you get to work with a subset of the tables that you are allowed to access via the database administrator. This is why mature ORMs have mapping files (which are considered excess by RoR) - they help isolate your app from what others are doing with the tables.
Please don't feel that I'm trying to attack your position.
Don't worry - I try to debate reasonably even if I think people are trying to do this:)
I'd like to know if there's something ugly waiting for me around the corner.
I just don't know - and that is what worries me! What would seriously concern me is that although RoR expresses some good ideas, it is very new and much of what it uses is in beta. I would not use any new product for a large app until it had a few years to mature.
I use things like JDO/Hibernate with Java, and (very occasionally) PHP because they have been around for years, are out of beta, and the issues regarding their use are well understood. This is NOT the case with RoR.
I don't think I do- I have been dealing with XML for years. However, there is always a first time.
A schema defines what elements are allowed in a given collection. For example, there are a number of elements. These can be contained in other elements as defined by the schema.
You can't add a msstyle:xxx element to that style: list because it won't validate against the schema.
So you add new namespaces with additional schemas.
"XML Schema in fact permits multiple schema components to be imported, from multiple namespaces, and they can be referred to in both definitions and declarations."
Unfortunately, the OpenDocument standard effectively disallows doing this in a number of ways. First, it doesn't require foreign elements to be preserved, thus if someone extends it, no other implementation has to retain any of that data and can silently discard it.
This is not preventing the original XML file being extended by the addition of new elements. Applications are supposed to be allowed to silently discard elements in namespaces they don't understand.
The point of the discussion was that Microsoft (or some other vendor) could add features to the OpenDocument format without breaking its use by other applications.
namespaces only work if you're adding entirely new elements, not if you want to change existing ones.
Yes - one vendor should not be changing the elements used by another.
the vast majority of data operations do not require any SQL code, and are freely portable across database platforms. Every Rails app I've built so far runs without modification on MySQL and Oracle.
I would suggest this is simply not the case for applications of even moderate compexity. If you don't use SQL code in Rails you often end up with serious performance problems (such as the N+1 fetch issue) which mature ORMs automatically handle.
Even when you need to do something that requires some embedded SQL, usually it is easy to restrict it to something platform-neutral.
I don't find that. Anything serious requires things like subselects and SQL functions. These are not portable. A mature ORM will automatically translate their portable query languages into the specific dialect of the particular database. Why should I use anything less that the full features of what might be an expensive database? Hibernate or JDO allow you to do this yet remain portable. Sticking to some hypothetical minimal subset of SQL is an inefficient waste in my view.
Also, at the risk of being pedantic; Ruby on Rails does not depend on ActiveRecord
I keep hearing this sort of thing: Ruby on Rails is fine as long as you don't use it as provided! My response is why is the system as provided so bad?
As for Og - it may be good, but to suggest I should build serious commercial apps with something that is at a beta level 0.2-0.3 is a bit of wishful thinking.
Um, the whole point of an open standard format is that it is an open standard -- you can't just add random new things to it, it wouldn't be compliant to the open standard any more.
Yes it would. That is the point of XML, hence the X for eXtensible. You CAN add random new things to it, through the use of your own namespaces. There are standard ways to do this.
What you're asking Microsoft to do here would in fact be exactly what they normall do; embrace and extend. And it would be bad for all the reasons it is normally bad: it would make files that claim to be OpenDocument files no longer work with OpenDocument-compliant UAs. Thus fragmenting the marketplace.
It would not make them no longer work. That is the point of using XML. Anyone can add anything but it has to be within their own namespace. Any program is free to ignore anyone else's namespace.
Microsoft can embrace and extend all they like, but if they extent the XML format legitimately (a big if, I agree, but the use of DTDs and schemas can ensure this), then this will have no effect on portability or compatibility.
You know, like they did with HTML and the DOM
No, because HTML is a file format. XML is a recipe for how to make file formats.
Although, to be honest, I am not a fan of OO XML-based compressed formats. They might have created the new format from the scratch and make it much more cleaner.
I really like it. As it is XML, I can easily transform it to other XML (or text) formats, and use standard free tools to parse and analyse it.
One of the reasons for XML is to save you from having to write formats (and associated processing tools and libraries) from scratch. Use of XML has allowed other applications (such as KOffice) to rapidly provide support for OO file formats.
Did you ever notice how science changes its anwsers so damn often. But the Bible stays the same.
No it doesn't! Haven't you heard about the process called 'translation'? The meaning of many passages has changed as a result of copying errors. The classic one is the substitution of the word 'virgin' for the word 'almah' which should really mean 'young woman'.
Also, use of common words in many languages change meaning with time.
"Microsoft will not support OpenDocument in its next version of Office 12 as it believed the format to be inferior"
If the format is 'inferior', then extend it! The X in XML (which is used by OpenDocument) stands for 'eXtensible'. XML is designed to allow document formats to be extended in a way which still allows portability and does not break compatibility.
Microsoft have make extensive use of XML for years, so they know this. This comment is simply pure FUD.
In their defense however, DBMS's have often evolved far faster than the specs could keep up resulting in dozens of different ways to do something the specs didn't originally cover. However, my forgiveness ends right where the spec catches up and then the dbms developers fail to add compatibility to their product. The fear that compatibility will leave room open for customers to migrate to a competing product is exactly why the USA is about 2 to 3 years behind in technology right now.
Hundreds of thousands of developers already write code that is easy to migrate between different database products. Systems like Hibernate and the Java JDO API include the option to use full-featured portable query languages (HSQL or JDOQL). These languages are translated to optimised vendor-specific SQL at run time. (Incidentally, one of the many faults of the hugely over-hyped Ruby on Rails is that it does not include such a portable language, and forces use of raw SQL). This can work very effectively as a huge amount of effort has gone into the efficiency of the generated SQL.
Pressure for portability has reached the stage where some database vendors (such as Oracle) are now backing new portable APIs (such as EJB3) and are having to focus more on quality, and not tying developers into their SQL dialect.
There is no need for developers to stick to vendor-specific SQL anymore in most situations.
The problem only is, that the simple ideas of the string theory
I disagree that they are simple. String theory implies that the fundamental units of the universe have a variety of properties (vibration, tension, length) yet provides no clear reason why such units should exist, or why they have such properties, or what those properties actually mean (as they are unlikely to be ever directly measured or observed). 'Just because the math works' is not sufficient...
(which is usually the physical theory behind the multiple dimensional universe explainations)
I think this is 'putting the cart before the horse'. There have been multi-dimensional theories of gravitational interaction for a long time. Simply because string theory requires multiple dimensions itself means it tends to be mentioned whenever multiple dimensions are discussed. However, it does not provide evidence for string theory either way, as you can have multiple dimensions without string theory, and string theory does not suggest that any of the considerable additional dimensions it requires are macroscopic.
Someone has called this the "Sarajevo Effect'. It occurs whenever a power-dependant connurbation above some ill-defined size losses its power for more than a day or two. Without power in its various forms, westernized cities cannot sustain their inhabitants for very long.
I don't know what the definition of 'westernized' is, but this sort of thing does not have to happen. When an earthquate devastated Kobe years back the Japanese did not riot. Instead former criminal gangs helped the authorities distribute food and supplies.
But you can't feel even such big things as atoms either. So instead of assuming their existence, would you say "when trying to explain chemical interaction, math works as if there were atoms, with 'valence', 'electronegativity', that seem to interact in this and that ways, but that's all just equations".
Atoms aren't considered to be fundamental.
IANAP, but I think that the additional mental effort, required to think of theoretial entities as nonexistent-prohections-of-math is unnecessery: phisics and math people have plenty of other reasons to go crazy;)
I think is is very important, otherwise the idea that strings are 'real' can prevent the investigation of other, perhaps simpler and more fundamental, ways of looking at things.
Birds are well known to be descendants of dinosaurs.
Not necessarily. There is some evidence that birds co-existed with dinosaurs for a long time. It could be that birds and some dinosaurs have a common ancestor.
Its not circular - the vibrations of strings is well defined with an extremely elegant forumla - circular strings are slightly different, but still very elegantly defined.
I realise it isn't really circular; I was using the fact one vibration is eventually defined in terms of another to illustrate a point - that string theory does not seem much like a fundamental theory, as there are still things that need to be explained - what are these 'strings', and why do they 'vibrate' and experience 'tension'?
I could understand an approach which said 'we have an elegant mathematical model which allows us to potentially calculate gravitational and other interactions within a single framework. The math works as if these vibrating entities exist'.
What I don't like is the assumption that because the math seems like it might work at some point in the future, therefore strings (and other M-theory constructs) actually exist. That is a huge step and totally unjustfied at this point.
probably ending up with a nice elegant explanation like m-theory.
That is not elegant as I understand the word!
Trying to explain real-world phenomena and physical properties such as (for example) vibration and tension using microscopic strings (the 2D aspect of M-Theory) which themselves are supposed to experience vibration and tension is kind of pointless[sic] and circular to me...
I don't know if that was sarcasm (I guess it was) and I'm not a proponent of ID, but I find it very odd that such a creature has evolved. The chances of that happening are infinitesimal
Not at all. The presence of a parasite is going to effect a host in some way, and all it takes is gradual evolution of certain effects over millions of years...
How many people could be provoked into a flamewar over string theory?
Pretty easily in my experience! String Theory is highly controversial in some ways. For many physicists it is the way forward in explaining just about everything. For other scientists (like me) it looks like nothing more than mathematical games, playing about with weird ideas at energy scales so high that it is unlikely they can ever be tested.
Your use of help wanted ads to prove your point is still possibly the least useful evidence I've seen since I started reading Slashdot.
I feel this is a huge exaggeration, especially as you still have not provided evidence of why. Job profiling is a very common way to check what technologies are in use both in companies and generally.
The absense of one layer of the stack doesn't make any point in particular as most open source based websites are going to be built fairly pragmatically.
If you leave out one layer of the stack, it isn't LAMP! That is my point.
If you have huge traffic, you use a load ballancer and multiple servers.
Sorry, doesn't work for sites which need write transactions. They have to have sophisticated application-scope write caches.
If you have huge data needs, then you tear out the MySQL and maybe move up to Postgress or a commercial database.
Then it isn't LAMP. That is my point.
You start with LAMP, then as you grow you port and adapt as needed. Sometimes you do part with LAMP and part with something else... that's the beauty of the platform - it's flexible compatible and fairly fast.
This is not practical, as the LAMP approach mainly makes use of rich embedded SQL within the application. Switching subsequently to a different dialect of SQL on a different database can be a major exercise. This is why many major sites (such as E-Bay) use portable query languages and ORMs to isolate themselves from database specifics.
Your are wrong to apply some standard that says only applications that write large numbers of transactions matter.
Depends on your definition of 'big site'. I would contend that a serious site would require the ability to handle persistent sessions and writes.
Websites and applications are more likely to be used in a read mode by the user anyway.
Read mode still doesn't work for high volume sites that need any kind of session storage.
Regardless, I suppose you thinkg that some of the CMS, forum software and ad servers out there don't do any writing...
I didn't say that they didn't do any writing. It is when you have to have serious high volume write traffic that the problem arises.
If you keep defining 'big-ass site' as the the kind of sites which are mainly read-only and can be handled by LAMP, then you will get the answer you want.
I am talking generally.
As far as switching to LAMP goes, you don't just tear out legacy systems on a lark because PHP is newer and shinier that whatever.
Sorry, but for some of the technologies I have been mentioning, LAMP is legacy. LAMP has been around for a while, and I am talking about sites that have been installing J2EE etc within the past few years.
Nothing you've said changes the only assertion I ever made: your original evidence sucked.
You never provided a good reason for suckage.
As I recall you were using positions being hired to make the claim that no one has big LAMP sites.
I didn't say that at all. I said that many of the biggest sites that are frequently claimed to be LAMP aren't - they may use key aspects of LAMP (Linux, or Python or Apache), but LAMP is the combination, or at least that is how I understand it. I certainly did not say that 'no one has big LAMP sites'; just that I did not know of that many. There are various definitions of 'big'!
My assertion is that LAMP alone, although very effective in many situations, just doesn't have all it takes for the real 'big-ass' sites, which need things like very high reliability and transactional control. Simply providing a high volume of mainly read-only traffic, as many sites frequently listed as showing how good technologies such as (for example) PHP are, does not count as in my view. Like it or not, complex systems like J2EE and Oracle do have what it takes to handle such requirements, which is why they is used in sites like stock exchanges which may need to handle volumes of up to tens of thousands of write transactions per second.
E-Bay - perhaps one of the highest volume sites on the internet has to handle enormous quantities of transactions and sessions. They use a combination of J2EE, Oracle, Linux and Solaris. (this is not based on just job evidence - the company state this). I'm sure that if they felt they could have saved money and time by switching to PHP and MySQL, they would!
Slashdot Mirror
In spite of the title, the article does not state 'Linux Five Years Away From Mainstream'. In states that 'Linux is five years away from mainstream use in Enterprise IT infrastructures. This is all about high-end data-centre stuff - a niche use. This article is confusing a very specialised use of Linux with it's general use as, for example, a mid-range server where it has proved it's successfulness for years. There is further confusion where the article mentions that 'many are re-evaluating Linux use' (many turns out to be 5 CIOs out of a panel of 12).
I don't know whether this article is deliberate FUD, or just a confused mess. I suspect the latter.
So there you have it, Natural Selection. It only allows through time, the good genes to pass, the genes that are responsible for allowing the creature to best co-exist in it's habitat.
No. It is far more complex that that. Evolution can be driven by things that have nothing at all to do with environment - look at things like the peacock's tain for example - something that is positively disadvantageous regarding environment. However, there are well-known selection mechanisms that allow even such 'bad' features to evolve - it is to do with competition within a species, not the environment.
Now, since we don't have a time machine, we CANNOT falsify historical evolution. It's just a theory, and absent a time machine we won't ever be able to test it.
Of course you can test it. You can make predictions about the way things could have evolved and what intermediate forms may have been present. You can then look for such forms in fossils. For example, there have been several theories about the lineage of whales, and fossil finds have helped test these theories.
In this sense evolution is a lot like cosmology. We can't go back to the early stages of the universe, but we can predict what should be there then look at distant (effectively 'fossil') light with telescopes.
Yes, smart people still trump over stupid people in most aspects of life, but stupid people still reproduce. Civilization has removed the engine through which drives the evolution of the species.
Not necessarily. Pressure for evolution does not have to be external - it can be driven by, for example, the preferences of members of a species about who they mate with. As long as women are selective about their male partners and men are the same then there will be evolution.
But because you are still in orbit, you are still under the influence of Earth's gravity.
Yes, but the gravity you experience is zero. If you are free-falling, even in a gravitional field, you don't feel any force (apart from very tiny tidal effects).
The idea is the users will have a chance to get use to OpenOffice, before they have to get use to linux.
Which quite honestly is a bigger change than changing from M$ Office to OpenOffice.
You and I may have no problem changing OS'es just like that, but they are dealing with general users that wont be, and will simply be expecting there computers to just work.
Having performed exactly this sort of migration, I completely disagree. It is the switch between Office systems that is the main issue. For a typical commercial user of workstations a Linux desktop can, if set up right, be immediately useable by anyone who has used a typical Windows desktop: icons for office applications, directory exploring, browser, e-mail etc. can made visible and then the user can get started - the computer 'just works'.
The big transition is in the way that the user will do various tasks in the office suite - multiple document management, mail merge etc.
Are you talking about legacy schemas, or tables designed for use with RoR?
:)
This does include legacy and current schemas. The way most commercial (and government) database work is that you simply don't get to design the tables for just your app - you get to work with a subset of the tables that you are allowed to access via the database administrator. This is why mature ORMs have mapping files (which are considered excess by RoR) - they help isolate your app from what others are doing with the tables.
Please don't feel that I'm trying to attack your position.
Don't worry - I try to debate reasonably even if I think people are trying to do this
I'd like to know if there's something ugly waiting for me around the corner.
I just don't know - and that is what worries me! What would seriously concern me is that although RoR expresses some good ideas, it is very new and much of what it uses is in beta. I would not use any new product for a large app until it had a few years to mature.
I use things like JDO/Hibernate with Java, and (very occasionally) PHP because they have been around for years, are out of beta, and the issues regarding their use are well understood. This is NOT the case with RoR.
No, you misunderstand.
I don't think I do- I have been dealing with XML for years. However, there is always a first time.
A schema defines what elements are allowed in a given collection. For example, there are a number of elements. These can be contained in other elements as defined by the schema.
You can't add a msstyle:xxx element to that style: list because it won't validate against the schema.
So you add new namespaces with additional schemas.
See http://www.w3.org/TR/xmlschema-0/
"XML Schema in fact permits multiple schema components to be imported, from multiple namespaces, and they can be referred to in both definitions and declarations."
Unfortunately, the OpenDocument standard effectively disallows doing this in a number of ways. First, it doesn't require foreign elements to be preserved, thus if someone extends it, no other implementation has to retain any of that data and can silently discard it.
This is not preventing the original XML file being extended by the addition of new elements. Applications are supposed to be allowed to silently discard elements in namespaces they don't understand.
The point of the discussion was that Microsoft (or some other vendor) could add features to the OpenDocument format without breaking its use by other applications.
namespaces only work if you're adding entirely new elements, not if you want to change existing ones.
Yes - one vendor should not be changing the elements used by another.
the vast majority of data operations do not require any SQL code, and are freely portable across database platforms. Every Rails app I've built so far runs without modification on MySQL and Oracle.
I would suggest this is simply not the case for applications of even moderate compexity. If you don't use SQL code in Rails you often end up with serious performance problems (such as the N+1 fetch issue) which mature ORMs automatically handle.
Even when you need to do something that requires some embedded SQL, usually it is easy to restrict it to something platform-neutral.
I don't find that. Anything serious requires things like subselects and SQL functions. These are not portable. A mature ORM will automatically translate their portable query languages into the specific dialect of the particular database. Why should I use anything less that the full features of what might be an expensive database? Hibernate or JDO allow you to do this yet remain portable. Sticking to some hypothetical minimal subset of SQL is an inefficient waste in my view.
Also, at the risk of being pedantic; Ruby on Rails does not depend on ActiveRecord
I keep hearing this sort of thing: Ruby on Rails is fine as long as you don't use it as provided! My response is why is the system as provided so bad?
As for Og - it may be good, but to suggest I should build serious commercial apps with something that is at a beta level 0.2-0.3 is a bit of wishful thinking.
Um, the whole point of an open standard format is that it is an open standard -- you can't just add random new things to it, it wouldn't be compliant to the open standard any more.
Yes it would. That is the point of XML, hence the X for eXtensible. You CAN add random new things to it, through the use of your own namespaces. There are standard ways to do this.
What you're asking Microsoft to do here would in fact be exactly what they normall do; embrace and extend. And it would be bad for all the reasons it is normally bad: it would make files that claim to be OpenDocument files no longer work with OpenDocument-compliant UAs. Thus fragmenting the marketplace.
It would not make them no longer work. That is the point of using XML. Anyone can add anything but it has to be within their own namespace. Any program is free to ignore anyone else's namespace.
Microsoft can embrace and extend all they like, but if they extent the XML format legitimately (a big if, I agree, but the use of DTDs and schemas can ensure this), then this will have no effect on portability or compatibility.
You know, like they did with HTML and the DOM
No, because HTML is a file format. XML is a recipe for how to make file formats.
Although, to be honest, I am not a fan of OO XML-based compressed formats. They might have created the new format from the scratch and make it much more cleaner.
I really like it. As it is XML, I can easily transform it to other XML (or text) formats, and use standard free tools to parse and analyse it.
One of the reasons for XML is to save you from having to write formats (and associated processing tools and libraries) from scratch. Use of XML has allowed other applications (such as KOffice) to rapidly provide support for OO file formats.
Did you ever notice how science changes its anwsers so damn often. But the Bible stays the same.
No it doesn't! Haven't you heard about the process called 'translation'? The meaning of many passages has changed as a result of copying errors. The classic one is the substitution of the word 'virgin' for the word 'almah' which should really mean 'young woman'.
Also, use of common words in many languages change meaning with time.
So, sorry, but the bible is not static.
From the article:
"Microsoft will not support OpenDocument in its next version of Office 12 as it believed the format to be inferior"
If the format is 'inferior', then extend it! The X in XML (which is used by OpenDocument) stands for 'eXtensible'. XML is designed to allow document formats to be extended in a way which still allows portability and does not break compatibility.
Microsoft have make extensive use of XML for years, so they know this. This comment is simply pure FUD.
In their defense however, DBMS's have often evolved far faster than the specs could keep up resulting in dozens of different ways to do something the specs didn't originally cover. However, my forgiveness ends right where the spec catches up and then the dbms developers fail to add compatibility to their product. The fear that compatibility will leave room open for customers to migrate to a competing product is exactly why the USA is about 2 to 3 years behind in technology right now.
Hundreds of thousands of developers already write code that is easy to migrate between different database products. Systems like Hibernate and the Java JDO API include the option to use full-featured portable query languages (HSQL or JDOQL). These languages are translated to optimised vendor-specific SQL at run time. (Incidentally, one of the many faults of the hugely over-hyped Ruby on Rails is that it does not include such a portable language, and forces use of raw SQL). This can work very effectively as a huge amount of effort has gone into the efficiency of the generated SQL.
Pressure for portability has reached the stage where some database vendors (such as Oracle) are now backing new portable APIs (such as EJB3) and are having to focus more on quality, and not tying developers into their SQL dialect.
There is no need for developers to stick to vendor-specific SQL anymore in most situations.
The problem only is, that the simple ideas of the string theory
I disagree that they are simple. String theory implies that the fundamental units of the universe have a variety of properties (vibration, tension, length) yet provides no clear reason why such units should exist, or why they have such properties, or what those properties actually mean (as they are unlikely to be ever directly measured or observed). 'Just because the math works' is not sufficient...
(which is usually the physical theory behind the multiple dimensional universe explainations)
I think this is 'putting the cart before the horse'. There have been multi-dimensional theories of gravitational interaction for a long time. Simply because string theory requires multiple dimensions itself means it tends to be mentioned whenever multiple dimensions are discussed. However, it does not provide evidence for string theory either way, as you can have multiple dimensions without string theory, and string theory does not suggest that any of the considerable additional dimensions it requires are macroscopic.
Someone has called this the "Sarajevo Effect'. It occurs whenever a power-dependant connurbation above some ill-defined size losses its power for more than a day or two. Without power in its various forms, westernized cities cannot sustain their inhabitants for very long.
I don't know what the definition of 'westernized' is, but this sort of thing does not have to happen. When an earthquate devastated Kobe years back the Japanese did not riot. Instead former criminal gangs helped the authorities distribute food and supplies.
But you can't feel even such big things as atoms either. So instead of assuming their existence, would you say "when trying to explain chemical interaction, math works as if there were atoms, with 'valence', 'electronegativity', that seem to interact in this and that ways, but that's all just equations".
;)
Atoms aren't considered to be fundamental.
IANAP, but I think that the additional mental effort, required to think of theoretial entities as nonexistent-prohections-of-math is unnecessery: phisics and math people have plenty of other reasons to go crazy
I think is is very important, otherwise the idea that strings are 'real' can prevent the investigation of other, perhaps simpler and more fundamental, ways of looking at things.
Birds are well known to be descendants of dinosaurs.
Not necessarily. There is some evidence that birds co-existed with dinosaurs for a long time. It could be that birds and some dinosaurs have a common ancestor.
Its not circular - the vibrations of strings is well defined with an extremely elegant forumla - circular strings are slightly different, but still very elegantly defined.
I realise it isn't really circular; I was using the fact one vibration is eventually defined in terms of another to illustrate a point - that string theory does not seem much like a fundamental theory, as there are still things that need to be explained - what are these 'strings', and why do they 'vibrate' and experience 'tension'?
I could understand an approach which said 'we have an elegant mathematical model which allows us to potentially calculate gravitational and other interactions within a single framework. The math works as if these vibrating entities exist'.
What I don't like is the assumption that because the math seems like it might work at some point in the future, therefore strings (and other M-theory constructs) actually exist. That is a huge step and totally unjustfied at this point.
probably ending up with a nice elegant explanation like m-theory.
That is not elegant as I understand the word!
Trying to explain real-world phenomena and physical properties such as (for example) vibration and tension using microscopic strings (the 2D aspect of M-Theory) which themselves are supposed to experience vibration and tension is kind of pointless[sic] and circular to me...
I don't know if that was sarcasm (I guess it was) and I'm not a proponent of ID, but I find it very odd that such a creature has evolved. The chances of that happening are infinitesimal
Not at all. The presence of a parasite is going to effect a host in some way, and all it takes is gradual evolution of certain effects over millions of years...
How is that flamebait?
I agree - it is a valid point of view.
How many people could be provoked into a flamewar over string theory?
Pretty easily in my experience! String Theory is highly controversial in some ways. For many physicists it is the way forward in explaining just about everything. For other scientists (like me) it looks like nothing more than mathematical games, playing about with weird ideas at energy scales so high that it is unlikely they can ever be tested.
Your use of help wanted ads to prove your point is still possibly the least useful evidence I've seen since I started reading Slashdot.
I feel this is a huge exaggeration, especially as
you still have not provided evidence of why. Job profiling is a very common way to check what technologies are in use both in companies and generally.
The absense of one layer of the stack doesn't make any point in particular as most open source based websites are going to be built fairly pragmatically.
If you leave out one layer of the stack, it isn't LAMP! That is my point.
If you have huge traffic, you use a load ballancer and multiple servers.
Sorry, doesn't work for sites which need write transactions. They have to have sophisticated application-scope write caches.
If you have huge data needs, then you tear out the MySQL and maybe move up to Postgress or a commercial database.
Then it isn't LAMP. That is my point.
You start with LAMP, then as you grow you port and adapt as needed. Sometimes you do part with LAMP and part with something else... that's the beauty of the platform - it's flexible compatible and fairly fast.
This is not practical, as the LAMP approach mainly makes use of rich embedded SQL within the application. Switching subsequently to a different dialect of SQL on a different database can be a major exercise. This is why many major sites (such as E-Bay) use portable query languages and ORMs to isolate themselves from database specifics.
Your are wrong to apply some standard that says only applications that write large numbers of transactions matter.
Depends on your definition of 'big site'. I would contend that a serious site would require the ability to handle persistent sessions and writes.
Websites and applications are more likely to be used in a read mode by the user anyway.
Read mode still doesn't work for high volume sites that need any kind of session storage.
Regardless, I suppose you thinkg that some of the CMS, forum software and ad servers out there don't do any writing...
I didn't say that they didn't do any writing. It is when you have to have serious high volume write traffic that the problem arises.
If you keep defining 'big-ass site' as the the kind of sites which are mainly read-only and can be handled by LAMP, then you will get the answer you want.
I am talking generally.
As far as switching to LAMP goes, you don't just tear out legacy systems on a lark because PHP is newer and shinier that whatever.
Sorry, but for some of the technologies I have been mentioning, LAMP is legacy. LAMP has been around for a while, and I am talking about sites that have been installing J2EE etc within the past few years.
Nothing you've said changes the only assertion I ever made: your original evidence sucked.
You never provided a good reason for suckage.
As I recall you were using positions being hired to make the claim that no one has big LAMP sites.
I didn't say that at all. I said that many of the biggest sites that are frequently claimed to be LAMP aren't - they may use key aspects of LAMP (Linux, or Python or Apache), but LAMP is the combination, or at least that is how I understand it. I certainly did not say that 'no one has big LAMP sites'; just that I did not know of that many. There are various definitions of 'big'!
My assertion is that LAMP alone, although very effective in many situations, just doesn't have all it takes for the real 'big-ass' sites, which need things like very high reliability and transactional control. Simply providing a high volume of mainly read-only traffic, as many sites frequently listed as showing how good technologies such as (for example) PHP are, does not count as in my view. Like it or not, complex systems like J2EE and Oracle do have what it takes to handle such requirements, which is why they is used in sites like stock exchanges which may need to handle volumes of up to tens of thousands of write transactions per second.
E-Bay - perhaps one of the highest volume sites on the internet has to handle enormous quantities of transactions and sessions. They use a combination of J2EE, Oracle, Linux and Solaris. (this is not based on just job evidence - the company state this). I'm sure that if they felt they could have saved money and time by switching to PHP and MySQL, they would!