By the time this becomes reality there will be so many alter-nets(tm) available that real discourse will be beyond the censor's perview.
(I take credit for coining the term 'Alternet' - unless someone can find prior art).
If worse comes to worse, we can all start using TCP/IP over Carrier Pigeon (which may have more bandwidth than current technologies under certain circumstances).
From my experience it costs more in the valuable time of an architect/engineer/system admin to haggle with the vendor about his responsiblities to uphold a support agreement, than simply managing the frigging thing in-house (with a rare exception here and there for proprietary integrated hardware/software systems - which you shouldn't be buying anyway and shows short sighted planning on your architect's part if you do).
The cheapest alternative, IMHO, is to run a cluster of identical Linux servers and have a well stocked spare parts closet. For mission critical applications there is no replacement for:
1. Redundancy.
2. Instant repairs by people on my payroll.
For the most part, a computer is a computer. It has through-put limitations which determine how big your cluster starts off, and grows based on measurements of usage. Slap an SLB infront of a cluster, and you are nearly infinitely scalable (provided you have the money to add servers to your cluster, and upgrade/add switches/routers to the cluster front-end; its not rocket science).
The biggest problem I see with the procurement/development process is that is all centers around the fiscal year. No one plans 5 or 10 years out anymore. Given our shortsightedness, is it any wonder we end up holding the bag on a poorly defined network architecture?
This is where you, and many others are not thinking holistically about your chosen profession (assuming you are a developer). Think about this: what if I find myself needing to use queues on a regular basis to integrate with my customer's current interfaces? If I have a standard module that I can use from job to job, I will be more successful with each passing job because I will have leveraged code-reuse. Seeing that, wouldn't it behoove me to build such a tool if none existed? Others in similar situations could also benefit from this OS development - thus raising the bar of software development as a whole. This is essentially the model we have seen work so well with Perl over its lifetime.
Your perspective is exactly what is sucking the life out of software development, and making our clients and the companies we work for see us not as valuable computer craftsmen, scientists and artisans, but instead as interchangeable code monkeys - and the source of our output simply intellectual property to be jealously guarded. Your perspective leads to throw-away development - each project being a unique 'reinvent the wheel' operation that always ends with spotty results. This mindset of the developers - and thus the way they tell their story to their clients and bosses through words and deeds - is why so many of us have been outsourced.
I will grant that there may be developers who use the tools you support to effectively and speedily produce highly useful applications for their clients. On the other hand I have seen few, if any such operations in practice - and yet have many examples of just the opposite at my fingertips.
Fiscal responsibility is just another term for shortsightedness. We save money in this year, yet end up paying for our hasty decisions in years to come above and beyond what we would have payed had we invested in the craft of software development.
If the entertainment industry has its way - we might well end up in a strange topsy-turvy world where recordings of the past simply disappear from the mainstream, memories become short, and we go back to painting on the walls of our collective dens.
Not bloody likely given the billions (with a 'B') probably needed to control a block of spectrum at a high power output(see sales of wireless spectrum that occurred in U.S. earlier this year).
I doubt they will let Joe Blow buy a particular range of spectrum for low-power use in the few miles surrounding his abode. Low power spectrum, as established recently in the U.S. is having problems due to bleed over from nearby stations - endangering business models for the small guys.
You are confusing Object Oriented programming with an Object Database. They are two seperate things. ZODB is a database that stores Z-objects (hence ZOPE - Z-Object Publishing Environment).
You can extend Z-objects by adding meta-data variables (probably the wrong name for them - but this is how I associate these). You can use these same variables to index and search the object database.
The neat thing is you don't have to mess with the guts of the ZODB - it just works - you just use it and extend it as needed.
In an RDBMS world you have to define your logical data model beforehand. In the Zope world, you can create what you think are the right data structures, and then extend them as you go - without any of the problems associated with large RDBMS's. There is no pressure to 'get it right the first time' - thus enhancing the speed of iterative development cycles.
I have one project that I managed that really needed an object model, as opposed to an RDBMS model (it was basically keeping track of new transport technology that is constantly changing as our network architecture changes). I tried to get the IT team to build a generic data structure that could be extended - they balked and forced me and my customers to define a logical data model ('we have had 20 years experience doing this - we know what is best', they said; yeah, right). Immediately after it shipped (late), we installed a new piece of hardware - which broke their data model (we emphasized the unknown aspects - but they refused to take that into account). Zope and the ZODB would have solved this problem easily. This same project is years overdue and massively over budget; I will never let this happen again - prefering to do my own development in most cases.
With an RDBMS you are required to try to fit a square peg in a round hole, or modify the database (not an easy or quick thing to do on a complex relational database). With and ODBMS (Object Database Management System) - you can make changes on the fly in your code without having to monkey with the DB itself.
It is a completely new paradigm that I can see is confusing to some people steeped in the standard methodology (dogma?) of the RDBMS world...
What you wrote and what you meant were two different things from my perspective.
After your clarification, I have to agree with your take on this - the JCP is less 'bazaar' and more 'cathedral', and certainly more so when compared to Linux.
Ability to publish zope objects with SOAP CORBA support. Message queues
SOAP and CORBA are data transport protocols. What would stop you from writing a product in python to handle these formats? Message queues are a physical implementation of those protocols. Again, you can implement your own queues in python (or any other language for that matter) This can be handled external to the Zope framework and passed into Zope via external methods.
Object relational layer
I'm not sure what you are referring to here. You can index and associate all sorts of meta-data with your zope objects - thereby relating the objects - is that what you were referring to? Additionally, Zope has a unique ability to acquire and use objects and permissions from folders above the current locale - so you could write a general purpose form that displays the contents of a directory for example, and apply it to multiple folders below without having to rewrite code.
transaction support for relational databases
Zope's ZODB (object database) does support transactions/rollback. Zope also has relational database plugins that allow you to communicate with all sorts of databases (oracle, sybase, mysql etc) - so if the database supports transactions - Zope should be able to make the database perform that function.
RMI or it's equavalent in python
You can write an external method to handle this, if needed, using jython. However, why bother with RMI when you can use sockets or python's Expect module? The benefit of these is not having to load anything special on the other end (I assume you would need Java on both ends of the RMI transaction).
Common logging infrastructure (log4j)
You could write an external method in python to write logs to a standard file - and call it from your applications.
Timed services (cron like device for calling certain code)
How about cron itself on a *nix system (you don't have to run ZOPE from Windoze - and I wouldn't recommend it anyway)? You can use cron to do certain administrative tasks for the overall system (such as packing the database). You could also write infrastructure pieces using python (or any other language for that matter) and have those modules run in cron (for example, an app to rotate your logs in the previous example).
Naming directory..... Many Many more thing that are in J2EE but not in zope.
There is a python-ldap package available via sourceforge.net - you can use this and an X.500 (LDAP) directory to manage your names. You would use an external method (python) to manage input/querying the directory.
But what it lacks more then anything else is good documentation. Yes there are lots of products but the vast majority of them have no more then a one sentence explation.
I will agree that the documentation for Zope 2.X is not optimal (but there is certainly a lot of it - the Zopebook 2.6 version is 495 pages long). I am hoping the Zope X3 will have better documentation (several books on the subject can be preordered for a December or January delivery). X3 will serve as a testbed for new development paradigms, as well as bringing development tools in-line with some of the issues developers have complained about.
The important aspect that you are missing is you can extend Zope via products and external python/other applications to get most, if not all of the functionality you mention here. If you really want to dig into the code, you can even modify the framework itself - since it is open source. Can you modify other frameworks in a similar fashion, or are you limited to what the vendor has p
stable system certainly doesn't emerge by a succession of miracles -- it emerges by a very clearly defined process
Not necessarily so. Agile development is more akin to an evolutionary movement toward a stable state, as opposed to a clearly defined process. Users/developers play with and provide input/patches about successive versions of the application until the 'right' solution (in the practical, metaphysical, moral, and esthetic planes) jells into some form of stability - where changes then occur more slowly over the lifespan of the application.
Zope has: Built-in object database (hence Z Object Publishing Environment - ZOPE). Built-in http server (Medusa), and ftp server. Ability to integrate with other http servers (i.e. Apache). Built-in scripting/application language (Python - and you can add Perl if desired) Built-in ability to connect to traditional relational databases, if needed. WEBDAV compliant. Built-in support for XML, HTML, DTML, TAL, TALES, METAL, and CSS. Ability to extend the environment by building modules that become integral to the site. Web client based development and administration - with access control built-in and fully configurable to your needs. If you can reach it from the network, you can develop and administer it. A large stable of free/open source modules that can be loaded (Plone - a full function CRM solution, Zwiki - wikiwiki web clone, just to name a few). Built-in ability to cluster a site across multiple machines (can be architected to serve behind an SLB for scalability, or in seperate geographical locations to provide local access to shared resources).
This is the fastest development environment I have seen - bar none. The biggest benefit comes from the object database - you don't have to think about a logical or physical data model beyond the needs of your application - you don't have to worry about how structures are defined in the database. You can move your data structures inside of your scripts directly into the object database as-is without having to monkey with table structures and all of the other baggage a relational database carries with it. Once you understand and use the object database, you never want to go back. Of course, you can attach to SQL databases, and do the silly walk if needed.
I set up a CRM solution using Plone that has been up and working for 6 months now with minimal time babysitting it. Adjunct to that, I have built several unique apps far quicker than our IT department could possibly accomplish using J2EE (we have several projects through that group that are years overdue and over budget - hence my move to Zope for internal development of critical support functions that can not wait).
Among the principles behind the Agile Manifesto are several that are instructive:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
Zope has helped me be successful with all of the above. How do your tools measure up?
With the extension of copyright lengths it is quickly becoming impossible to determine if what you are doing independently does not break copyright. This is the same problem patents face; the sheer size of active patents and copyrights makes exhaustive searches nearly impossible, unless you have a lot of money to invest in the search.
Most individuals and small businesses do not have the resources to engage in a thorough search. This only serves to stifle the advancement of new forms of art, science and technology. This is not in the public's best interest - both from a consumer standpoint, as well as the small developer.
My concern is that they will suppress the alternatives.
It is all well and good if a bunch of us decide to develop new technologies to broadcast our own programming using our own standards across the internet (for example - nothing wrong with that, as I am not violating any copyright laws etc).
My concern is that by selective enforcement of these rules, the FCC could suppress innovation, and force those of us who want alternatives into their 'consumer' box.
I thought government and corporations served the needs of the people - not the other way around.
That is not true. His limited sampling makes that faulty assumption. There is no statistical evidence to support his hypothesis, or for that matter to support the idea that a 'professional' encyclopedia does not suffer this same problem from a different angle: generalists writing about specific subjects they are not conversant in.
I have seen excellent articles on various subjects in Wikipedia. I have seen bad articles in mainstream encyclopedias (both print and CDrom). This alone is not enough to make any conclusions.
While I may agree that the possibility embodied in his hypothesis exists, there has been no evidence presented that proves it. The faulty assumption he (and you) make is that ipso facto the 'regression to the mean' is working here, while there have been no facts to support that conclusion.
1. The assumption that the writing of a professional encyclopedia writer is more 'truthful' than that of neophytes. No one has a monopoly on the truth - and assuming the 'professionals' are less likely to be biased is horse pucky.
2. The assumption that one sample article will tell you the over-all value of the Wikipedia. After he extolls the virtues of the scientific method, he then uses an example that is statistically meaningless.
The reality is every form of media is subject to inaccuracy for several reasons: a) The information was recorded incorrectly to begin with. b) The writer and/or source of the information has an agenda which misrepresenting the facts serves. c) Typographical errors.
This will always be the case. The only way to know 'for sure' is to either witness the event first hand (and even that is subject to perceptual anamolies) or use many different sources and determine if they agree on the issue at hand. Even then, you have to trust that they all got it right. It is possible they didn't.
When all is said and done there is not much difference between professional media and that produced by volunteers. The key difference is money, and the fact that a large internet operation of volunteers is more likely to come across people with more than a passing interest in the subjects. Additionally, while the quality of the writing may vary, you can certainly be sure of getting a large number of points of view - much more interesting in many contexts IMHO.
I don't know about you, but I grew up being fed what I was 'supposed' to know and think from the media most of my life. Having the vast resources of the internet is a balance against abuses of the mainstream media.
I believe what he meant to say was 'If you enforce the local general societal rules already on the books, then there is no need for a global Internet Government'
What he is saying is that any 'government' on an internet-wide standpoint needs to stick to technical communication interconnection specifications - leave the policing to the police in the respective nations.
There are already organizations - such as INTERPOL - for coordinating police forces internationally. Use what we already have more effectively IMHO.
Independents need to stop being independent and bring a strong middling voice into the highly polarized major parties.
As long as we continue to negotiate and compromise between extreme views there is hope for us. Once everyone decides to take their ball home and not play, that is when anarchy reigns.
The more factionalized we become, the harder it will be to remain one nation undivided - look at the disruption coalition style governments wreak when there is a falling out (India and Isreal are good examples of how this multi-party system can lead to disruptions, sometimes at key points when the government needs to speak with one voice).
This is why, while I leaned towards independent movements when I was younger, I have come down firmly in my middle age inside of an existing party - to bring moderation over the zealots who have stolen the heart of both parties IMHO.
The voice of the American People is a moderate voice - elections show this time and time again. It is time for that voice to be heard.
Ward Cunningham: I had a few things that I wanted to accomplish when I created wiki. My specific purpose for the first wiki was to create an environment where we might link together each other's experience to discover the pattern language of programming. I had previously worked with a HyperCard? stack that was set up to achieve the same kind of goal. I knew people liked to read and author in that HyperCard? stack, but it was single user. When we started the PLoP? [Pattern Languages of Programming]? series of conferences, and realized that what we really wanted to do was start a new literature, I decided that I needed to take that HyperCard? stack and find a web equivalent.
I had read, and squirrled away this article some time ago, and recalled the information incorrectly. I was correct that the central idea behind Wiki evolved from Apple's hypercard stack - I misattributed Ward as the creator of that probably because 'CRC card' is phonetically similar to 'hypercard'. My appologies.
Here is a link to the original wiki created by Ward Cunningham - who was also the creator of Apple's Hypercard software. Wiki is the logical extension of that idea:
Slashdot Mirror
By the time this becomes reality there will be so many alter-nets(tm) available that real discourse will be beyond the censor's perview.
(I take credit for coining the term 'Alternet' - unless someone can find prior art).
If worse comes to worse, we can all start using TCP/IP over Carrier Pigeon (which may have more bandwidth than current technologies under certain circumstances).
The cheapest alternative, IMHO, is to run a cluster of identical Linux servers and have a well stocked spare parts closet. For mission critical applications there is no replacement for:
For the most part, a computer is a computer. It has through-put limitations which determine how big your cluster starts off, and grows based on measurements of usage. Slap an SLB infront of a cluster, and you are nearly infinitely scalable (provided you have the money to add servers to your cluster, and upgrade/add switches/routers to the cluster front-end; its not rocket science).
The biggest problem I see with the procurement/development process is that is all centers around the fiscal year. No one plans 5 or 10 years out anymore. Given our shortsightedness, is it any wonder we end up holding the bag on a poorly defined network architecture?
This is where you, and many others are not thinking holistically about your chosen profession (assuming you are a developer). Think about this: what if I find myself needing to use queues on a regular basis to integrate with my customer's current interfaces? If I have a standard module that I can use from job to job, I will be more successful with each passing job because I will have leveraged code-reuse. Seeing that, wouldn't it behoove me to build such a tool if none existed? Others in similar situations could also benefit from this OS development - thus raising the bar of software development as a whole. This is essentially the model we have seen work so well with Perl over its lifetime.
Your perspective is exactly what is sucking the life out of software development, and making our clients and the companies we work for see us not as valuable computer craftsmen, scientists and artisans, but instead as interchangeable code monkeys - and the source of our output simply intellectual property to be jealously guarded. Your perspective leads to throw-away development - each project being a unique 'reinvent the wheel' operation that always ends with spotty results. This mindset of the developers - and thus the way they tell their story to their clients and bosses through words and deeds - is why so many of us have been outsourced.
I will grant that there may be developers who use the tools you support to effectively and speedily produce highly useful applications for their clients. On the other hand I have seen few, if any such operations in practice - and yet have many examples of just the opposite at my fingertips.
Fiscal responsibility is just another term for shortsightedness. We save money in this year, yet end up paying for our hasty decisions in years to come above and beyond what we would have payed had we invested in the craft of software development.
"He who forgets the past is doomed to repeat it" - Attributed to Che Guevara (but I think someone else said this before he did).
To put it another way, throwing out the baby with the bath water is a 'bad thing'.
Long Live DVD Burners.
If the entertainment industry has its way - we might well end up in a strange topsy-turvy world where recordings of the past simply disappear from the mainstream, memories become short, and we go back to painting on the walls of our collective dens.
Not bloody likely given the billions (with a 'B') probably needed to control a block of spectrum at a high power output(see sales of wireless spectrum that occurred in U.S. earlier this year).
I doubt they will let Joe Blow buy a particular range of spectrum for low-power use in the few miles surrounding his abode. Low power spectrum, as established recently in the U.S. is having problems due to bleed over from nearby stations - endangering business models for the small guys.
Privatization is no panacea.
You are confusing Object Oriented programming with an Object Database. They are two seperate things. ZODB is a database that stores Z-objects (hence ZOPE - Z-Object Publishing Environment).
You can extend Z-objects by adding meta-data variables (probably the wrong name for them - but this is how I associate these). You can use these same variables to index and search the object database.
The neat thing is you don't have to mess with the guts of the ZODB - it just works - you just use it and extend it as needed.
In an RDBMS world you have to define your logical data model beforehand. In the Zope world, you can create what you think are the right data structures, and then extend them as you go - without any of the problems associated with large RDBMS's. There is no pressure to 'get it right the first time' - thus enhancing the speed of iterative development cycles.
I have one project that I managed that really needed an object model, as opposed to an RDBMS model (it was basically keeping track of new transport technology that is constantly changing as our network architecture changes). I tried to get the IT team to build a generic data structure that could be extended - they balked and forced me and my customers to define a logical data model ('we have had 20 years experience doing this - we know what is best', they said; yeah, right). Immediately after it shipped (late), we installed a new piece of hardware - which broke their data model (we emphasized the unknown aspects - but they refused to take that into account). Zope and the ZODB would have solved this problem easily. This same project is years overdue and massively over budget; I will never let this happen again - prefering to do my own development in most cases.
With an RDBMS you are required to try to fit a square peg in a round hole, or modify the database (not an easy or quick thing to do on a complex relational database). With and ODBMS (Object Database Management System) - you can make changes on the fly in your code without having to monkey with the DB itself.
It is a completely new paradigm that I can see is confusing to some people steeped in the standard methodology (dogma?) of the RDBMS world...
What you wrote and what you meant were two different things from my perspective.
After your clarification, I have to agree with your take on this - the JCP is less 'bazaar' and more 'cathedral', and certainly more so when compared to Linux.
SOAP and CORBA are data transport protocols. What would stop you from writing a product in python to handle these formats? Message queues are a physical implementation of those protocols. Again, you can implement your own queues in python (or any other language for that matter) This can be handled external to the Zope framework and passed into Zope via external methods.
I'm not sure what you are referring to here. You can index and associate all sorts of meta-data with your zope objects - thereby relating the objects - is that what you were referring to? Additionally, Zope has a unique ability to acquire and use objects and permissions from folders above the current locale - so you could write a general purpose form that displays the contents of a directory for example, and apply it to multiple folders below without having to rewrite code.
Zope's ZODB (object database) does support transactions/rollback. Zope also has relational database plugins that allow you to communicate with all sorts of databases (oracle, sybase, mysql etc) - so if the database supports transactions - Zope should be able to make the database perform that function.
You can write an external method to handle this, if needed, using jython. However, why bother with RMI when you can use sockets or python's Expect module? The benefit of these is not having to load anything special on the other end (I assume you would need Java on both ends of the RMI transaction).
You could write an external method in python to write logs to a standard file - and call it from your applications.
How about cron itself on a *nix system (you don't have to run ZOPE from Windoze - and I wouldn't recommend it anyway)? You can use cron to do certain administrative tasks for the overall system (such as packing the database). You could also write infrastructure pieces using python (or any other language for that matter) and have those modules run in cron (for example, an app to rotate your logs in the previous example).
There is a python-ldap package available via sourceforge.net - you can use this and an X.500 (LDAP) directory to manage your names. You would use an external method (python) to manage input/querying the directory.
I will agree that the documentation for Zope 2.X is not optimal (but there is certainly a lot of it - the Zopebook 2.6 version is 495 pages long). I am hoping the Zope X3 will have better documentation (several books on the subject can be preordered for a December or January delivery). X3 will serve as a testbed for new development paradigms, as well as bringing development tools in-line with some of the issues developers have complained about.
The important aspect that you are missing is you can extend Zope via products and external python/other applications to get most, if not all of the functionality you mention here. If you really want to dig into the code, you can even modify the framework itself - since it is open source. Can you modify other frameworks in a similar fashion, or are you limited to what the vendor has p
Not necessarily so. Agile development is more akin to an evolutionary movement toward a stable state, as opposed to a clearly defined process. Users/developers play with and provide input/patches about successive versions of the application until the 'right' solution (in the practical, metaphysical, moral, and esthetic planes) jells into some form of stability - where changes then occur more slowly over the lifespan of the application.
Is this a process? Maybe. Clearly defined? Never.
Zope kicks both of their [censored] IMHO.
Zope has:
Built-in object database (hence Z Object Publishing Environment - ZOPE).
Built-in http server (Medusa), and ftp server.
Ability to integrate with other http servers (i.e. Apache).
Built-in scripting/application language (Python - and you can add Perl if desired)
Built-in ability to connect to traditional relational databases, if needed.
WEBDAV compliant.
Built-in support for XML, HTML, DTML, TAL, TALES, METAL, and CSS.
Ability to extend the environment by building modules that become integral to the site.
Web client based development and administration - with access control built-in and fully configurable to your needs. If you can reach it from the network, you can develop and administer it.
A large stable of free/open source modules that can be loaded (Plone - a full function CRM solution, Zwiki - wikiwiki web clone, just to name a few).
Built-in ability to cluster a site across multiple machines (can be architected to serve behind an SLB for scalability, or in seperate geographical locations to provide local access to shared resources).
This is the fastest development environment I have seen - bar none. The biggest benefit comes from the object database - you don't have to think about a logical or physical data model beyond the needs of your application - you don't have to worry about how structures are defined in the database. You can move your data structures inside of your scripts directly into the object database as-is without having to monkey with table structures and all of the other baggage a relational database carries with it. Once you understand and use the object database, you never want to go back. Of course, you can attach to SQL databases, and do the silly walk if needed.
I set up a CRM solution using Plone that has been up and working for 6 months now with minimal time babysitting it. Adjunct to that, I have built several unique apps far quicker than our IT department could possibly accomplish using J2EE (we have several projects through that group that are years overdue and over budget - hence my move to Zope for internal development of critical support functions that can not wait).
Among the principles behind the Agile Manifesto are several that are instructive:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
Zope has helped me be successful with all of the above. How do your tools measure up?
The last time I checked extortion is not a legitimate way of making money.
Earning a living is not bad - its how you earn that living that counts. Microsoft is one of the worse in this regard.
With the extension of copyright lengths it is quickly becoming impossible to determine if what you are doing independently does not break copyright. This is the same problem patents face; the sheer size of active patents and copyrights makes exhaustive searches nearly impossible, unless you have a lot of money to invest in the search.
Most individuals and small businesses do not have the resources to engage in a thorough search. This only serves to stifle the advancement of new forms of art, science and technology. This is not in the public's best interest - both from a consumer standpoint, as well as the small developer.
My concern is that they will suppress the alternatives.
It is all well and good if a bunch of us decide to develop new technologies to broadcast our own programming using our own standards across the internet (for example - nothing wrong with that, as I am not violating any copyright laws etc).
My concern is that by selective enforcement of these rules, the FCC could suppress innovation, and force those of us who want alternatives into their 'consumer' box.
I thought government and corporations served the needs of the people - not the other way around.
That is not true. His limited sampling makes that faulty assumption. There is no statistical evidence to support his hypothesis, or for that matter to support the idea that a 'professional' encyclopedia does not suffer this same problem from a different angle: generalists writing about specific subjects they are not conversant in.
I have seen excellent articles on various subjects in Wikipedia. I have seen bad articles in mainstream encyclopedias (both print and CDrom). This alone is not enough to make any conclusions.
While I may agree that the possibility embodied in his hypothesis exists, there has been no evidence presented that proves it. The faulty assumption he (and you) make is that ipso facto the 'regression to the mean' is working here, while there have been no facts to support that conclusion.
He speaks of truth, yet fails to perceive it.
His argument is flawed on two counts:
1. The assumption that the writing of a professional encyclopedia writer is more 'truthful' than that of neophytes. No one has a monopoly on the truth - and assuming the 'professionals' are less likely to be biased is horse pucky.
2. The assumption that one sample article will tell you the over-all value of the Wikipedia. After he extolls the virtues of the scientific method, he then uses an example that is statistically meaningless.
The reality is every form of media is subject to inaccuracy for several reasons:
a) The information was recorded incorrectly to begin with.
b) The writer and/or source of the information has an agenda which misrepresenting the facts serves.
c) Typographical errors.
This will always be the case. The only way to know 'for sure' is to either witness the event first hand (and even that is subject to perceptual anamolies) or use many different sources and determine if they agree on the issue at hand. Even then, you have to trust that they all got it right. It is possible they didn't.
When all is said and done there is not much difference between professional media and that produced by volunteers. The key difference is money, and the fact that a large internet operation of volunteers is more likely to come across people with more than a passing interest in the subjects. Additionally, while the quality of the writing may vary, you can certainly be sure of getting a large number of points of view - much more interesting in many contexts IMHO.
I don't know about you, but I grew up being fed what I was 'supposed' to know and think from the media most of my life. Having the vast resources of the internet is a balance against abuses of the mainstream media.
I believe what he meant to say was 'If you enforce the local general societal rules already on the books, then there is no need for a global Internet Government'
What he is saying is that any 'government' on an internet-wide standpoint needs to stick to technical communication interconnection specifications - leave the policing to the police in the respective nations.
There are already organizations - such as INTERPOL - for coordinating police forces internationally. Use what we already have more effectively IMHO.
Imagine there's no script kiddies
It isn't hard to do
No more spam in my in-box
And no MS Windows too
Independents need to stop being independent and bring a strong middling voice into the highly polarized major parties.
As long as we continue to negotiate and compromise between extreme views there is hope for us. Once everyone decides to take their ball home and not play, that is when anarchy reigns.
The more factionalized we become, the harder it will be to remain one nation undivided - look at the disruption coalition style governments wreak when there is a falling out (India and Isreal are good examples of how this multi-party system can lead to disruptions, sometimes at key points when the government needs to speak with one voice).
This is why, while I leaned towards independent movements when I was younger, I have come down firmly in my middle age inside of an existing party - to bring moderation over the zealots who have stolen the heart of both parties IMHO.
The voice of the American People is a moderate voice - elections show this time and time again. It is time for that voice to be heard.
...and judicious application of nose grease...
Huh?
This was the best line in the whole screed...LMAO!!
From an interview with Ward:
I had read, and squirrled away this article some time ago, and recalled the information incorrectly. I was correct that the central idea behind Wiki evolved from Apple's hypercard stack - I misattributed Ward as the creator of that probably because 'CRC card' is phonetically similar to 'hypercard'. My appologies.
Here is a link to the original wiki created by Ward Cunningham - who was also the creator of Apple's Hypercard software. Wiki is the logical extension of that idea:
http://c2.com/cgi/wiki?TheOriginalWiki
If they are really smart, the document content will be in XML, and the different output formats will be generated using xslt and/or CSS.
;)
No fuss, no muss, and no nasty edit-trail to clean up.
Thanks for that synopsis. Seems the reality is more convoluted than first impressions imply.