In his exceptional book "The Underground history of American Education" John Taylor Gatto details that the stated intent of our education system is to produce permanent childhood.
He explains that, due to an unusual set of circumstances at the time the USA was formed, young people where given adult responsibility and adult work. The concept of the teen years as a part of childhood did not exist. It was only with the introduction of mass forced schooling that young people lost the ability to deal with adult responsibilities. In fact Gatto contends that compulsion schooling has produced a measurable drop in literacy, inventive thought and maturity.
Some quotes:
Now, you needn't have studied marketing to know that there are two groups of people who can always be convinced to consume more than they need to: addicts and children. School has done a pretty good job of turning our children into addicts, but it has done a spectacular job of turning our children into children. Again, this is no accident. Theorists from Plato to Rousseau to our own Dr. Inglis knew that if children could be cloistered with other children, stripped of responsibility and independence, encouraged to develop only the trivializing emotions of greed, envy, jealousy, and fear, they would grow older but never truly grow up. In the 1934 edition of his once well-known book Public Education in the United States, Ellwood P. Cubberley detailed and praised the way the strategy of successive school enlargements had extended childhood by two to six years, and forced schooling was at that point still quite new. This same Cubberley - who was dean of Stanford's School of Education, a textbook editor at Houghton Mifflin, and Conant's friend and correspondent at Harvard - had written the following in the 1922 edition of his book Public School Administration: "Our schools are . . . factories in which the raw products (children) are to be shaped and fashioned.. . . And it is the business of the school to build its pupils according to the specifications laid down."
This is from the book:
The second document, the gigantic Behavioral Science Teacher Education Project, outlined teaching reforms to be forced on the country after 1967. If you ever want to hunt this thing down, it bears the U.S. Office of Education Contract Number OEC-0-9-320424-4042 (B10). The document sets out clearly the intentions of its creators--nothing less than "impersonal manipulation" through schooling of a future America in which "few will be able to maintain control over their opinions," an America in which "each individual receives at birth a multi-purpose identification number" which enables employers and other controllers to keep track of underlings and to expose them to direct or subliminal influence when necessary. Readers learned that "chemical experimentation" on minors would be normal procedure in this post-1967 world, a pointed foreshadowing of the massive Ritalin interventions which now accompany the practice of forced schooling.
The Behavioral Science Teacher Education Project identified the future as one "in which a small elite" will control all important matters, one where participatory democracy will largely disappear. Children are made to see, through school experiences, that their classmates are so cruel and irresponsible, so inadequate to the task of self-discipline, and so ignorant they need to be controlled and regulated for society's good. Under such a logical regime, school terror can only be regarded as good advertising. It is sobering to think of mass schooling as a vast demonstration project of human inadequacy, but that is at least one of its functions.
Post-modern schooling, we are told, is to focus on "pleasure cultivation" and on "other attitudes and skills compatible with a non-work world." Thus the socialization classroom of the century's beginning--itself a radical departure from schooling for mental and character development--can be seen to ha
I am currently researching DBMAIL. This is an GPLed email system that permits one to store mail in an SQL database. The advantage of this is that all writes are transactional, permitting overview
Scalability
Dbmail is as scalable as the database system that is used for the mail storage. In theory millions of accounts can be managed using dbmail.
One could, for example, run 4 different servers with the pop3 daemon each connecting to the same database (cluster) server.
Manageability
Dbmail is based upon a database. Dbmail can be managed by changing settings in the database (f.e. using PHP/Perl/SQL), without needing shell access.
Speed
Dbmail uses very efficient, database specific queries for retrieving mail information. This is much faster then parsing a filesystem.
Security
Dbmail has got nothing to do with the filesystem or interaction with other programs in the Unix environment which need special permissions.
Dbmail is as secure as the database it's based upon.
Flexibility.
Changes on a Dbmail system (adding of users, changing passwords etc.) are effective immediately.
Other thoughts:
Running the mail store on NFS has been an unmitigated disaster. Lost mail, nfs lock problems, slow response and other issues.
Speculation about GFS and LUSTRE are just that. I have never met anyone successfully using a gfs/iscsi/god knows what in anything remotely resembling a production environment.
It would be terrific to be able to backup the customer's mail. There is no effective way to do this with nfs/maildir/what have you. A database supports this natively
I am a little disappointed that dovecot was not the base for the imap server in dbmail, but the provided imap server seems pretty full featured.
There is a fundamental problem with Blastwave and every one of the available efforts to adapt a new package management system to Solaris. Solaris has an existing package management system and all the dependencies in this system are ignored or overwritten by the new system. Alternatively the new package management system will take over and require that it be used exclusively. Let's look at a few examples:
1) rpm.rutgers.edu - this is a terrific resource that has some major advantages over blastwave. It will take your existing Solaris packages and migrate them to the rpm database, however this is a one shot deal and you are expected to manage your software with rpm from that point on. What do I do if I want to install a patch from sun or a new SUNW package? 2) Netbsd pkgsrc : Rocking good software collection and spectacular cross platform goodness, but it has no concept of the host package management system. Also I miss the ability to apt-get update ; apt-get upgrade . The source base changes every quarter. I had high hopes for http://solarpack.sourceforge.net/ but development has been dropped. 3) Sunfreeware. Solaris packages, but no dependency info is used at all. 4) Blastwave, ibiblio, and a few others. These systems use solaris packages, but don't integrate them with the Sun provided dependency database. 5) Sun's own Companion CD has Sun maintained packages (albeit not very many) that do seem to do the trick. 6) Many efforts to port apt to Solaris as detailed here: http://solarpack.sourceforge.net/links.html#solari s
So the question is, what is the goal of all this? It looks to me like the purpose of a package management system is to minimize systems administrator labor. That means that I might be willing to manually create and maintain one or two packages, but if I am installing many packages I would like to have a dependable repository of secure, bug free packages that I can draw upon. Furthermore I need a method of doing a simple mass upgrade of packages.
The major reason for using Solaris is the get a stable platform. Solaris binaries from 10 years ago will still run unmodified on Solaris 10 from March of this year. Joel Sparsky has written at length on the subject of a stable API as being the underpinning of Microsoft's success. Industry is still willing to pay a premium for Sun hardware and software because they have a need to minimize change in the datacenter. If I want to install Gforge http://people.debian.org/~bayle/ on a stock Debian Sarge machine it will auto install more than 20 packages. On Solaris many of these packages are already provided by sun. Stripping your machine down to the kernel and a few other support packages and replacing the guts of the OS with Debian (or pkgsrc) doesn't seem to me to be the right way to go if you are looking for stability. Sun is the one making the commitment to support for 10 years not Debian. I would like to use as much Sun supported software as possible in setting up my machine.
I am responding to this post and not the quoted one below because it captures the arrogence
of the development community. I swim in a sea of web interfaces that use java script popups, flash
controlled buttons, java applets and god only knows what that are required to do my job.
Well, not exactly, but I think that you will find that many tools which evolved within UNIX
culture (not necessarily only on Linux) have much higher degree of built-in scriptability.
In addition to pretty (or not so pretty) GUIs, their designers felt obliged to incorporate an
alternative text-based interface, not to mention that many useful packages started from being
text-based and grew their GUI skins later on. In any case, most often everything that you can
do with keyboard and mouse (and then some) can be done via some kind of command line.
This was the case about 5 or 6 years ago, but that trend has been abandoned. MOST of the tools
that I am encountering today have no scripting API. The mozilla group has no interest in making the
the browser accessable to text tools (I asked), and the makers or all these new point-n-click
interfaces don't have a clue what I am talking about.
I get the impression that you want to record mouse movements and keystrokes and whatnot,
but given that I don't know the specific tasks that you are trying to "macro" I think this method of automation is bass-ackwards.
I can't think of very many tasks in linux that cannot be done with console based alternatives to
graphical ones. That being the case, you can control and automate all aspects of a console application using bash or the shell of your choice.
But if you must automate an application that only has a graphical interface, this application
should do it.
I have just completed writing a script using android
to setup ~300 domains on an anti-spam system that uses javascript popups and once again is REQUIRED by my job.
If I can paraphrase the above "boy you sure are stupid for wanting to automate your point-and-click
job. Why don't you badger the developers of the GUI to make it easier for you to write expect scripts?"
can you imagine what this must sound like to the people considering moving to linux (what in my opinion
are the most likely to move, the most "tech") , or to the developers themselves faced with armies of secretaries
who can barely figure out a web page?
Android itself is a pretty putrid piece of work that will not accomodate window moves or resizes, but it is
still better that the recommended gerd app that can only accomodate GTK programs.
The Hesiod file distribution system was developed by MIT for this purpose. It has been incorporated into BIND for a decade.
This is a quote from the man page for named.conf on solaris.
The hesiod class is for an information service from MIT's
Project Athena. It is used to share information about vari-
ous systems databases, such as users, groups, and printers.
More information can be found at ftp://athena-
dist.mit.edu/pub/ATHENA/usenix/athena_changes.PS. The key-
word hs is a synonym for hesiod.
iSCSI is a recognized standard
on
HyperSCSI Examined
·
· Score: 2, Interesting
I met Andre Hedrick at the linuxworld show, and thought he was very sharp. Don't dimiss him out of hand.
iSCSI has drivers for every OS you can imagine, written by CISCO, IBM, Microsoft, and released under the GPL. This is from the iscsi sourceforge page.
To attach to storage, you must also have an iSCSI-capable device connected to your network. The iSCSI device may be on the same LAN as your Linux host, or the iSCSI traffic may be routed using normal IP routing methods.
The daemon and the kernel driver are available under the terms of the GNU General Public License.
This implies for instance that one could boot ones diskless workstation from a collocated netapp on another continent, protected by a an IPsec tunnel.
While i could do something similar with ethernet layer tunneled over IP, it leads to many complications and difficult debugging. I have personal experiance with this, as this how our company runs its ethernet layer phone system.
This problem has been solved. In 1982 Paul Birch developed a new technique for dealing with the very long space elevator and associated problem.
http://www.paulbirch.net/OrbitalRings-I.zip
http://www.paulbirch.net/OrbitalRings-II.zip
http://www.paulbirch.net/OrbitalRings-III.zip
I got both Mandrake 8.1 and redhat 7.2 from the donkey. I waited weeks for the ftp sites to be free enough to get redhat 7.0. I got redhat 7.2 from the donkey in 6 hours.
I built slashcode pre release on openbsd the other day. My hands are still trembling. The thing is not set up to run on BSD. For instance in the make file is a cp command that will not work on BSD. They clearly have no intention to make this thing work with FreeBSD.
> www.greenglow.co.uk. Server: indy.legend.co.uk Address: 194.164.0.3 Name: www.greenglow.co.uk Address: 127.0.0.1 They are pointing the web server back at yourself! The ultimate postmodern self reference.
In his exceptional book "The Underground history of American Education" John Taylor Gatto details that the stated intent of our education system is to produce permanent childhood.
He explains that, due to an unusual set of circumstances at the time the USA was formed, young people where given adult responsibility and adult work. The concept of the teen years as a part of childhood did not exist. It was only with the introduction of mass forced schooling that young people lost the ability to deal with adult responsibilities. In fact Gatto contends that compulsion schooling has produced a measurable drop in literacy, inventive thought and maturity.
Some quotes:
This is from the book:
overview
Dbmail is as scalable as the database system that is used for the mail storage. In theory millions of accounts can be managed using dbmail. One could, for example, run 4 different servers with the pop3 daemon each connecting to the same database (cluster) server.
Dbmail is based upon a database. Dbmail can be managed by changing settings in the database (f.e. using PHP/Perl/SQL), without needing shell access.
Dbmail uses very efficient, database specific queries for retrieving mail information. This is much faster then parsing a filesystem.
Dbmail has got nothing to do with the filesystem or interaction with other programs in the Unix environment which need special permissions. Dbmail is as secure as the database it's based upon.
Changes on a Dbmail system (adding of users, changing passwords etc.) are effective immediately.
Other thoughts:
Running the mail store on NFS has been an unmitigated disaster. Lost mail, nfs lock problems, slow response and other issues.
Speculation about GFS and LUSTRE are just that. I have never met anyone successfully using a gfs/iscsi/god knows what in anything remotely resembling a production environment.
It would be terrific to be able to backup the customer's mail. There is no effective way to do this with nfs/maildir/what have you. A database supports this natively
I am a little disappointed that dovecot was not the base for the imap server in dbmail, but the provided imap server seems pretty full featured.
There is a fundamental problem with Blastwave and every one of the available efforts to adapt a new package management system to Solaris. Solaris has an existing package management system and all the dependencies in this system are ignored or overwritten by the new system. Alternatively the new package management system will take over and require that it be used exclusively. Let's look at a few examples:
i s
1) rpm.rutgers.edu - this is a terrific resource that has some major advantages over blastwave. It will take your existing Solaris packages and migrate them to the rpm database, however this is a one shot deal and you are expected to manage your software with rpm from that point on. What do I do if I want to install a patch from sun or a new SUNW package?
2) Netbsd pkgsrc : Rocking good software collection and spectacular cross platform goodness, but it has no concept of the host package management system. Also I miss the ability to apt-get update ; apt-get upgrade . The source base changes every quarter. I had high hopes for http://solarpack.sourceforge.net/ but development has been dropped.
3) Sunfreeware. Solaris packages, but no dependency info is used at all.
4) Blastwave, ibiblio, and a few others. These systems use solaris packages, but don't integrate them with the Sun provided dependency database.
5) Sun's own Companion CD has Sun maintained packages (albeit not very many) that do seem to do the trick.
6) Many efforts to port apt to Solaris as detailed here:
http://solarpack.sourceforge.net/links.html#solar
So the question is, what is the goal of all this? It looks to me like the purpose of a package management system is to minimize systems administrator labor. That means that I might be willing to manually create and maintain one or two packages, but if I am installing many packages I would like to have a dependable repository of secure, bug free packages that I can draw upon. Furthermore I need a method of doing a simple mass upgrade of packages.
The major reason for using Solaris is the get a stable platform. Solaris binaries from 10 years ago will still run unmodified on Solaris 10 from March of this year. Joel Sparsky has written at length on the subject of a stable API as being the underpinning of Microsoft's success. Industry is still willing to pay a premium for Sun hardware and software because they have a need to minimize change in the datacenter. If I want to install Gforge http://people.debian.org/~bayle/ on a stock Debian Sarge machine it will auto install more than 20 packages. On Solaris many of these packages are already provided by sun. Stripping your machine down to the kernel and a few other support packages and replacing the guts of the OS with Debian (or pkgsrc) doesn't seem to me to be the right way to go if you are looking for stability. Sun is the one making the commitment to support for 10 years not Debian. I would like to use as much Sun supported software as possible in setting up my machine.
This was the case about 5 or 6 years ago, but that trend has been abandoned. MOST of the tools that I am encountering today have no scripting API. The mozilla group has no interest in making the the browser accessable to text tools (I asked), and the makers or all these new point-n-click interfaces don't have a clue what I am talking about.
I have just completed writing a script using android to setup ~300 domains on an anti-spam system that uses javascript popups and once again is REQUIRED by my job. If I can paraphrase the above "boy you sure are stupid for wanting to automate your point-and-click job. Why don't you badger the developers of the GUI to make it easier for you to write expect scripts?" can you imagine what this must sound like to the people considering moving to linux (what in my opinion are the most likely to move, the most "tech") , or to the developers themselves faced with armies of secretaries who can barely figure out a web page?
Android itself is a pretty putrid piece of work that will not accomodate window moves or resizes, but it is still better that the recommended gerd app that can only accomodate GTK programs.
This is a quote from the man page for named.conf on solaris.
iSCSI has drivers for every OS you can imagine, written by CISCO, IBM, Microsoft, and released under the GPL. This is from the iscsi sourceforge page.
This implies for instance that one could boot ones diskless workstation from a collocated netapp on another continent, protected by a an IPsec tunnel. While i could do something similar with ethernet layer tunneled over IP, it leads to many complications and difficult debugging. I have personal experiance with this, as this how our company runs its ethernet layer phone system.
This problem has been solved. In 1982 Paul Birch developed a new technique for dealing with the very long space elevator and associated problem.
http://www.paulbirch.net/OrbitalRings-I.zip
http://www.paulbirch.net/OrbitalRings-II.zip
http://www.paulbirch.net/OrbitalRings-III.zip
I got both Mandrake 8.1 and redhat 7.2 from the donkey. I waited weeks for the ftp sites to be free enough to get redhat 7.0. I got redhat 7.2 from the donkey in 6 hours.
I built slashcode pre release on openbsd the other day. My hands are still trembling. The thing is not set up to run on BSD. For instance in the make file is a cp command that will not work on BSD. They clearly have no intention to make this thing work with FreeBSD.
> www.greenglow.co.uk. Server: indy.legend.co.uk Address: 194.164.0.3 Name: www.greenglow.co.uk Address: 127.0.0.1 They are pointing the web server back at yourself! The ultimate postmodern self reference.