For computer-driven color vision testing (such as measuring of discrimination thresholds), the standard is 14-bits per channel (e.g., http://www.crsltd.com/catalog/visage/indepth.html). That field is also one of the few holdouts for CRT use as they still have better optical properties than LCDs.
A non-color anormal man is just as good in color discrimination tests as a woman. However, cone opsin genes are carried on the X chromosome which causes men to manifest color deficiency an order of magnitude more often than women (who have another X to fall back on). The rate is 5-8% or so.
Actually its probably more like 15-20k USD per minute. Presumably, like most retailers, they make a lot more money in November-December than the rest of the year.
There are many serious problems with drug testing.
1- A proper drug test requires access to the medical records of the patient--otherwise there is no way to discriminate between controlled substances used legally (by prescription) vs illegally.
2- Urine testing reveals a large amount of additional medical information about the patient's condition beyond just drug use. It's more like looking at a bank statement than a credit report--you see it all. That information is private. And, only a handful of states regulate drug testing, putting that information at risk of exploitation.
3- Drug testing has a non-trivial false positive rate, which may be as high as 5%. As the prevalence of the condition decreases, so also must the false positive rate otherwise the test is not economical. When the false positive rate exceeds the prevalence times the correct positive rate, the test will identify more non-drug users than it will drug users.
4- Severity; drug testing does not easily distinguish between occasional and habitual use.
Finally, there are more effective methods for determining individual fitness for performance of a task, which focus on the ability to do the actual task. For example NASA uses computer-based hand-eye coordination tests (e.g. video games) for testing pilots' fitness to perform. This test is better than a drug test because it catches more ordinary conditions like fatigue and distraction, and it can be administered quickly and easily when needed, e.g. every time they are about to fly a mission.
Testing can, and should be used, for people in performance-critical positions--however, *drug* testing is both unreliable and insufficient, in addition to being a serious invasion of medical privacy.
AFAIK you already need a patched or at least properly configured kernel to get really good latency response. Planet CCRMA and the Debian Multimedia Project are two distros that come with LL kernels. Obviously these distros will stay on older versions until the BKL situation is resolved.
A sensible plan for such areas is to offer an insurance policy for rescue. They have something like this for climbers in Chamonix and apparently its a fairly reasonable cost. They basically have a rescue team working full time pulling people off the mountain. Europeans can be fairly reckless (e.g. the popularity of crazy-dangerous activities like paragliding). Anyhoo, there is a funny story about it in Krakauer's Eiger Dreams.
Basically, determining the order and invocation of triggers is a dependency resolution problem. This is done with by attaching semantic metadata to the trigger that specifies its requirements to the dependency-solver. For example-thing Y requires X to run first, thing Z always runs after Y, so we run X,Y,Z.
In Drupal the order of invocation is determined by sorting a list of "weights", which are actually coded by hand and the developers literally guess what weights might be good. Keep in mind there are over 1500 modules so it is essentially impossible for this guess to be anything other than a shot in the dark.
It gets worse as the notion of "weight" permeates the entire Drupal system from the very low level trigger invokation and node access grants all the way up to the user interface, and while it solves some ordering problems for short lists and known stable combinations of items, it rapidly becomes intractable or worse for anything else. (BTW the "sticky" node attribute is also problematic for the same reasons).
Trigger systems in an RDBMS deal with the dependency problem (e.g., BEFORE / AFTER / ON UPDATE, etc); so does aspect oriented programming. Package management systems (e.g. Debian apt) also deal with the dependency resolution problem for very large number of items (20k+ packages). Those are a couple places to look to get an idea for the type of semantics needed.
I have no problem recommending Drupal to people as long as I communicate to them how much work to expect for maintenance and customization beyond the default capabilities.
For a lot of people it's just fine, and certainly something like Plone has a much steeper learning curve.
Drupal is reasonably robust against XSS and injection attacks, unlike more than a few other PHP projects. Kudos for that. The security-announce list also keeps up to date with new problems, which are not too common, but every drupal admin had better be on it. I actually found an order-of-operations bug in the D5 input filter--not with security implications, but it did mess up the escaping of certain sequences. That is just to say that its not proven to be bug free.
Security-wise my main complaint is about the node access system... its just a crappy implementation. Roles stink, grants priority is a bug-prone disaster (along with all use of weight in general -- an aspect-oriented pre/post require system is what's needed, which, by the way, is neatly described with an RDF ontology--yet again, too bad Drupal can't actually describe those...), and access compositions are not well defined. A more complete OO system would have provided for more and better checkpoints. For a reasonably complex access control setup, it is much too easy to accidentally expose information to the wrong user, and there is far too much expertise required of users to get ACL settings right when they are creating a node.
And, if you need to use the system/ passthrough for file transfers, expect to need the help of an apache configuration expert (fortunately I am one, haha). God help you if you actually need independent control of attachments vs nodes.
Multiple categories don't make a semantic tagging system. Nor does free tagging. As long as there is no operator to specify the type of relation one cannot form actual sentences. There was actually an ontology module for D4 but it sort of went dead.
Anyhoo... yeah. I still use it, but it's not fun, and there is a whole category of requests that I get where my answer is "wait a few years and maybe it will be solved".
In my estimation Drupal has serious design flaws from the ground up. Beginning with ignorance of major programming paradigms that make for secure and scalable web services (e.g. model-view-controller), and what amounts to criminal negligence in the design of a basic hook and trigger system. When I first saw the "weight" feature in Drupal I immediately got a whiff of bad code-smell... turns out that bad code runs all the way to the core. The core developers also have developed their own private terminology (modules, themes, views, blocks...) that is extremely jargon-heavy and at best vague and not in agreement with standard terminology, at worst inconsistent with itself (e.g. category vs taxonomy vs vocabulary).
Just about every part of Drupal core and its modules suffers from a disease called "good enough for my site" where the developer stopped building abstractions exactly at the point where his/her particular requirement was satisfied. If that is also good enough for your site, consider yourself lucky.
Drupal gets tagging wrong by leaving out the semantic predicate from the RDF triple--or what I call loosely "Web 1.1". As a result all sorts of interesting ways of structuring information and workflow are impossible. Some core modules are allowed to abuse the tagging system for alternative purposes (forum). Its implementation of tagging keeps abrest with current buzzwords (e.g. "tag cloud") but is a nightmare for actual information repositories that span organizational operations and materials.
There is a serious case of TIMTOWTDI, but not in a good way, with over 1500 available modules in contrib, leaving the administrator to solve a giant matrix of modules X,Y,Z providing multiple variants on the same feature, each with random and weird limitations, incompatibilities, and serious worries about future compatibility and module lifespan. When I say matrix I'm not kidding--I have literally had to resort to tabulating information in spreadsheets to work out which module to use.
Drupal is also a fast-moving target. There is a major version release approximately once per year, and active core maintenance only covers the latest two versions (and the situation may be much worse for some contrib modules). This works out to a product lifecycle of two years for any Drupal site. Code customization is cited as the #1 reason for sites to not upgrade, which means you are looking at rewriting all of your customizations every two years. For any large scale site, customization is basically required because you will find all sorts of things in modules and the core that need changing (see "good enough for my site"), but can't be patched into the mainline. Compare that to something like Ubuntu-LTS which has a lifecycle of 5 years, and an upgrade process that is significantly easier than a core drupal upgrade. Just to keep this post on-topic, this implies that the book mentioned in the review will start heading to obsolescence in about 10 months.
Nonetheless Drupal easily wins over more "correct" CMFs (e.g. Zope/Plone) simply because it is operational and feature-packed out of the box, and the sheer volume of active developers outweighs the rather low quality code that is produced. AFAIK there is nothing better, though I certainly wish there was. My long-term future prediction is that Google will eventually have something that rivals Drupal and runs on the App Engine--but given their rather conservative front-end development schedule, it will probably take some time.
I'm all in favor of the alternatives and I'm a regular bike-commuter, but I have to admit cars really are the ideal transport system. They are fast, safe, simple to operate, weather-proof, and form a true end-to-end system (especially important in urban areas). The weight and power don't seem absurd to me... if I'm going to step into a box moving at 75mph it better be a capable one.
Anyways, in my estimation there are basically two problems -- 1) environmental factors, and 2) effect of human error in the control system (traffic jams, accidents, etc). The latter is solved easily enough by AI drivers, and the former is a bit of a logistical challenge but not impossible to solve given appropriate allocation of resources.
With oil companies posting profits in excess of $100b and similar amounts going into the Iraq war, its hard not to realize that someone is profiting greatly right now by obstructing progress in this area. If that money was redirected into solving aforementioned problems I'm sure we would be well on the way to a solution by now.
The top CS programs don't have "programming language" courses at all (actually they do, but the classes don't count towards degree credit). The ability to write simple programs is a prerequisite for entry, not something that is taught, and certainly not something that is taught "later", unless maybe you are talking about some school in siberian russia where they don't have computers. This simply makes no sense. Yeah, you gain experience through projects, but the focus is *always* on theory, from start to finish.
IMHO the tech school is a waste of intellect unless maybe you want to be an overpriced Oracle DBA or a.NET coder (*yawn*). Then again those pay a lot better than what I do (academic research)... To each his own. On the other hand, with a solid background in theory it is trivial to pick up those skills, giving you the ability to try out the cubicle life for a few years and move on if it doesn't suit.
The only real danger with a liberal arts school is low standards / grade inflation. If the academic standards are too low, the profs start to let laziness slide by, which is uninspiring at best. I'd take a close look at the CVs of the profs in the department--see if they have an active publication record on topics that haven't been rehashes of the same old idea for the last 10 years.
My other advice is to research the programs of the top schools. You might not have been accepted there, but if you take a close look at what is covered, you can figure out what you need to do to get an equivalent education (which is entirely possible regardless of where you "go" given sufficient motivation).
Caffeine is far less effective than ritalin/provigil/amphetamines. The latter have the ability to keep the mind and body at high performance for extended periods of time (48 hours+).
Even if you had a low enough tolerance and took enough caffeine to stay awake for 48 hours, the side effects would be so terrible that you would be barely functional. It's not an engineered drug, and as such it just can't compare.
The other interesting drug not discussed much in this thread is the beta-blockers. These are actually anti-anxiety and useful for staying calm in high-pressure interviews or performances (e.g., musicians use them also). This is just to point out that there are other types of performance enhancement than uppers.
TFA points out that it may be necessary or even a good idea to consider alternative uses of drugs beyond treatment -- i.e., enhancement. I don't think we need such things over-the-counter but I'd not be opposed to making prescription for enhancement purposes legal.
Dunno about the UIUC side, but a significant part of the UCB/ParLab grant includes research into applications.
There is also a recent paper that shows how the MapReduce pattern can be easily applied to just about every machine-learning algorithms with near-linear speedup. This stuff isn't just going to be used to make the next Clippy, but for more interesting stuff like video processing, speech recognition, sensor fusion in "smart" handhelds, etc.
The applications and the need exist, but so far they have not been practical, at least in part because of computing limitations.
It's not necessarily overselling. Statistical capacity planning has been an integral part of communications network design since the deployment of the first phone switches. To a first approximation, network use is poisson-distributed -- it is wasteful and expensive to allocate dedicated bandwidth to every node.
Emergent phenomena always breaks the statistical estimates, which is what we are currently seeing with the growth in popularity of P2P sharing and so on. It's not terribly surprising that Comcast and others don't know how to react. Ultimately they will need to increase capacity, that much is certain.
IMHO, from the customer rights point-of-view, the best thing they could do would be to specify in detail exactly what QoS is provided by the contract, and at the same time come up with a QoS strategy that is both fair and maximizes network use.
I also like how a minor version upgrade of Blackboard seemed to always require 6-12 hours of downtime while IT staff sorts it out. Real convenient in the middle of the semester.
Seems to be about on par with the Diebold voting system in terms of quality. Woe be the day their source code is leaked for the world to see.
Verisign does not "own" the domains -- they provide a service, not a product. The worth of a domain itself is irrelevant. The only question is, how much does it cost to operate the TLD servers and still make a reasonable profit margin (reasonable meaning that the employees of said operation would be sufficiently compensated to keep the operation running smoothly). I'd guess that in bulk, the cost is on the order of a few cents per domain.
A significant portion of education is taxpayer funded. Why should we spend money to support liberal arts programs with low standards? All degree programs should require approximately the same amount of effort. I'd rather have education be more affordable and more difficult.
That is why purchase transactions and personal data from amazon are served from a secure server. The secure server uses an independent cookie with the secure flag set, which cannot be transmitted except over https. Hijacking the unsecured session cookie won't get you much more than recommendations tailored to someone else's account. This is a standard design for a high-volume service that can't afford to have every page SSL encrypted.
The string-theoretic meaning of "orbifold" is not the same as its meaning in geometric topology, and according to Wikipedia has "no geometric interpretation". I'm not an expert on the subject but at first glance I'm fairly certain that Tymoczko's orbifold is in the general sense, not the string-theoretic one. Oops?
Slashdot Mirror
For computer-driven color vision testing (such as measuring of discrimination thresholds), the standard is 14-bits per channel (e.g., http://www.crsltd.com/catalog/visage/indepth.html). That field is also one of the few holdouts for CRT use as they still have better optical properties than LCDs.
A non-color anormal man is just as good in color discrimination tests as a woman. However, cone opsin genes are carried on the X chromosome which causes men to manifest color deficiency an order of magnitude more often than women (who have another X to fall back on). The rate is 5-8% or so.
Actually its probably more like 15-20k USD per minute. Presumably, like most retailers, they make a lot more money in November-December than the rest of the year.
There are many serious problems with drug testing.
1- A proper drug test requires access to the medical records of the patient--otherwise there is no way to discriminate between controlled substances used legally (by prescription) vs illegally.
2- Urine testing reveals a large amount of additional medical information about the patient's condition beyond just drug use. It's more like looking at a bank statement than a credit report--you see it all. That information is private. And, only a handful of states regulate drug testing, putting that information at risk of exploitation.
3- Drug testing has a non-trivial false positive rate, which may be as high as 5%. As the prevalence of the condition decreases, so also must the false positive rate otherwise the test is not economical. When the false positive rate exceeds the prevalence times the correct positive rate, the test will identify more non-drug users than it will drug users.
4- Severity; drug testing does not easily distinguish between occasional and habitual use.
Finally, there are more effective methods for determining individual fitness for performance of a task, which focus on the ability to do the actual task. For example NASA uses computer-based hand-eye coordination tests (e.g. video games) for testing pilots' fitness to perform. This test is better than a drug test because it catches more ordinary conditions like fatigue and distraction, and it can be administered quickly and easily when needed, e.g. every time they are about to fly a mission.
Testing can, and should be used, for people in performance-critical positions--however, *drug* testing is both unreliable and insufficient, in addition to being a serious invasion of medical privacy.
AFAIK you already need a patched or at least properly configured kernel to get really good latency response. Planet CCRMA and the Debian Multimedia Project are two distros that come with LL kernels. Obviously these distros will stay on older versions until the BKL situation is resolved.
A sensible plan for such areas is to offer an insurance policy for rescue. They have something like this for climbers in Chamonix and apparently its a fairly reasonable cost. They basically have a rescue team working full time pulling people off the mountain. Europeans can be fairly reckless (e.g. the popularity of crazy-dangerous activities like paragliding). Anyhoo, there is a funny story about it in Krakauer's Eiger Dreams.
Basically, determining the order and invocation of triggers is a dependency resolution problem. This is done with by attaching semantic metadata to the trigger that specifies its requirements to the dependency-solver. For example-thing Y requires X to run first, thing Z always runs after Y, so we run X,Y,Z.
In Drupal the order of invocation is determined by sorting a list of "weights", which are actually coded by hand and the developers literally guess what weights might be good. Keep in mind there are over 1500 modules so it is essentially impossible for this guess to be anything other than a shot in the dark.
It gets worse as the notion of "weight" permeates the entire Drupal system from the very low level trigger invokation and node access grants all the way up to the user interface, and while it solves some ordering problems for short lists and known stable combinations of items, it rapidly becomes intractable or worse for anything else. (BTW the "sticky" node attribute is also problematic for the same reasons).
Trigger systems in an RDBMS deal with the dependency problem (e.g., BEFORE / AFTER / ON UPDATE, etc); so does aspect oriented programming. Package management systems (e.g. Debian apt) also deal with the dependency resolution problem for very large number of items (20k+ packages). Those are a couple places to look to get an idea for the type of semantics needed.
I have no problem recommending Drupal to people as long as I communicate to them how much work to expect for maintenance and customization beyond the default capabilities.
For a lot of people it's just fine, and certainly something like Plone has a much steeper learning curve.
Drupal is reasonably robust against XSS and injection attacks, unlike more than a few other PHP projects. Kudos for that. The security-announce list also keeps up to date with new problems, which are not too common, but every drupal admin had better be on it. I actually found an order-of-operations bug in the D5 input filter--not with security implications, but it did mess up the escaping of certain sequences. That is just to say that its not proven to be bug free.
Security-wise my main complaint is about the node access system... its just a crappy implementation. Roles stink, grants priority is a bug-prone disaster (along with all use of weight in general -- an aspect-oriented pre/post require system is what's needed, which, by the way, is neatly described with an RDF ontology--yet again, too bad Drupal can't actually describe those...), and access compositions are not well defined. A more complete OO system would have provided for more and better checkpoints. For a reasonably complex access control setup, it is much too easy to accidentally expose information to the wrong user, and there is far too much expertise required of users to get ACL settings right when they are creating a node.
And, if you need to use the system/ passthrough for file transfers, expect to need the help of an apache configuration expert (fortunately I am one, haha). God help you if you actually need independent control of attachments vs nodes.
Multiple categories don't make a semantic tagging system. Nor does free tagging. As long as there is no operator to specify the type of relation one cannot form actual sentences. There was actually an ontology module for D4 but it sort of went dead.
Anyhoo... yeah. I still use it, but it's not fun, and there is a whole category of requests that I get where my answer is "wait a few years and maybe it will be solved".
In my estimation Drupal has serious design flaws from the ground up. Beginning with ignorance of major programming paradigms that make for secure and scalable web services (e.g. model-view-controller), and what amounts to criminal negligence in the design of a basic hook and trigger system. When I first saw the "weight" feature in Drupal I immediately got a whiff of bad code-smell... turns out that bad code runs all the way to the core. The core developers also have developed their own private terminology (modules, themes, views, blocks...) that is extremely jargon-heavy and at best vague and not in agreement with standard terminology, at worst inconsistent with itself (e.g. category vs taxonomy vs vocabulary).
:)
Just about every part of Drupal core and its modules suffers from a disease called "good enough for my site" where the developer stopped building abstractions exactly at the point where his/her particular requirement was satisfied. If that is also good enough for your site, consider yourself lucky.
Drupal gets tagging wrong by leaving out the semantic predicate from the RDF triple--or what I call loosely "Web 1.1". As a result all sorts of interesting ways of structuring information and workflow are impossible. Some core modules are allowed to abuse the tagging system for alternative purposes (forum). Its implementation of tagging keeps abrest with current buzzwords (e.g. "tag cloud") but is a nightmare for actual information repositories that span organizational operations and materials.
There is a serious case of TIMTOWTDI, but not in a good way, with over 1500 available modules in contrib, leaving the administrator to solve a giant matrix of modules X,Y,Z providing multiple variants on the same feature, each with random and weird limitations, incompatibilities, and serious worries about future compatibility and module lifespan. When I say matrix I'm not kidding--I have literally had to resort to tabulating information in spreadsheets to work out which module to use.
Drupal is also a fast-moving target. There is a major version release approximately once per year, and active core maintenance only covers the latest two versions (and the situation may be much worse for some contrib modules). This works out to a product lifecycle of two years for any Drupal site. Code customization is cited as the #1 reason for sites to not upgrade, which means you are looking at rewriting all of your customizations every two years. For any large scale site, customization is basically required because you will find all sorts of things in modules and the core that need changing (see "good enough for my site"), but can't be patched into the mainline. Compare that to something like Ubuntu-LTS which has a lifecycle of 5 years, and an upgrade process that is significantly easier than a core drupal upgrade. Just to keep this post on-topic, this implies that the book mentioned in the review will start heading to obsolescence in about 10 months.
Nonetheless Drupal easily wins over more "correct" CMFs (e.g. Zope/Plone) simply because it is operational and feature-packed out of the box, and the sheer volume of active developers outweighs the rather low quality code that is produced. AFAIK there is nothing better, though I certainly wish there was. My long-term future prediction is that Google will eventually have something that rivals Drupal and runs on the App Engine--but given their rather conservative front-end development schedule, it will probably take some time.
YMMV. Feel free to contradict.
I'm all in favor of the alternatives and I'm a regular bike-commuter, but I have to admit cars really are the ideal transport system. They are fast, safe, simple to operate, weather-proof, and form a true end-to-end system (especially important in urban areas). The weight and power don't seem absurd to me... if I'm going to step into a box moving at 75mph it better be a capable one.
Anyways, in my estimation there are basically two problems -- 1) environmental factors, and 2) effect of human error in the control system (traffic jams, accidents, etc). The latter is solved easily enough by AI drivers, and the former is a bit of a logistical challenge but not impossible to solve given appropriate allocation of resources.
With oil companies posting profits in excess of $100b and similar amounts going into the Iraq war, its hard not to realize that someone is profiting greatly right now by obstructing progress in this area. If that money was redirected into solving aforementioned problems I'm sure we would be well on the way to a solution by now.
Traffic circles are better! Stopping is obsolete technology.
I get about 10% better fuel efficiency by using cruise control. Unfortunately it's only practical in light traffic.
Humanities classes are not for reading/writing skills any more than CS classes are for programming skills.
The top CS programs don't have "programming language" courses at all (actually they do, but the classes don't count towards degree credit). The ability to write simple programs is a prerequisite for entry, not something that is taught, and certainly not something that is taught "later", unless maybe you are talking about some school in siberian russia where they don't have computers. This simply makes no sense. Yeah, you gain experience through projects, but the focus is *always* on theory, from start to finish.
.NET coder (*yawn*). Then again those pay a lot better than what I do (academic research)... To each his own. On the other hand, with a solid background in theory it is trivial to pick up those skills, giving you the ability to try out the cubicle life for a few years and move on if it doesn't suit.
IMHO the tech school is a waste of intellect unless maybe you want to be an overpriced Oracle DBA or a
The only real danger with a liberal arts school is low standards / grade inflation. If the academic standards are too low, the profs start to let laziness slide by, which is uninspiring at best. I'd take a close look at the CVs of the profs in the department--see if they have an active publication record on topics that haven't been rehashes of the same old idea for the last 10 years.
My other advice is to research the programs of the top schools. You might not have been accepted there, but if you take a close look at what is covered, you can figure out what you need to do to get an equivalent education (which is entirely possible regardless of where you "go" given sufficient motivation).
Caffeine is far less effective than ritalin/provigil/amphetamines. The latter have the ability to keep the mind and body at high performance for extended periods of time (48 hours+).
Even if you had a low enough tolerance and took enough caffeine to stay awake for 48 hours, the side effects would be so terrible that you would be barely functional. It's not an engineered drug, and as such it just can't compare.
The other interesting drug not discussed much in this thread is the beta-blockers. These are actually anti-anxiety and useful for staying calm in high-pressure interviews or performances (e.g., musicians use them also). This is just to point out that there are other types of performance enhancement than uppers.
TFA points out that it may be necessary or even a good idea to consider alternative uses of drugs beyond treatment -- i.e., enhancement. I don't think we need such things over-the-counter but I'd not be opposed to making prescription for enhancement purposes legal.
Dunno about the UIUC side, but a significant part of the UCB/ParLab grant includes research into applications.
There is also a recent paper that shows how the MapReduce pattern can be easily applied to just about every machine-learning algorithms with near-linear speedup. This stuff isn't just going to be used to make the next Clippy, but for more interesting stuff like video processing, speech recognition, sensor fusion in "smart" handhelds, etc.
The applications and the need exist, but so far they have not been practical, at least in part because of computing limitations.
It's not necessarily overselling. Statistical capacity planning has been an integral part of communications network design since the deployment of the first phone switches. To a first approximation, network use is poisson-distributed -- it is wasteful and expensive to allocate dedicated bandwidth to every node.
Emergent phenomena always breaks the statistical estimates, which is what we are currently seeing with the growth in popularity of P2P sharing and so on. It's not terribly surprising that Comcast and others don't know how to react. Ultimately they will need to increase capacity, that much is certain.
IMHO, from the customer rights point-of-view, the best thing they could do would be to specify in detail exactly what QoS is provided by the contract, and at the same time come up with a QoS strategy that is both fair and maximizes network use.
I also like how a minor version upgrade of Blackboard seemed to always require 6-12 hours of downtime while IT staff sorts it out. Real convenient in the middle of the semester.
Seems to be about on par with the Diebold voting system in terms of quality. Woe be the day their source code is leaked for the world to see.
Verisign does not "own" the domains -- they provide a service, not a product. The worth of a domain itself is irrelevant. The only question is, how much does it cost to operate the TLD servers and still make a reasonable profit margin (reasonable meaning that the employees of said operation would be sufficiently compensated to keep the operation running smoothly). I'd guess that in bulk, the cost is on the order of a few cents per domain.
The dirt it has to push around is also 1/4 weight.
A significant portion of education is taxpayer funded. Why should we spend money to support liberal arts programs with low standards? All degree programs should require approximately the same amount of effort. I'd rather have education be more affordable and more difficult.
That is why purchase transactions and personal data from amazon are served from a secure server. The secure server uses an independent cookie with the secure flag set, which cannot be transmitted except over https. Hijacking the unsecured session cookie won't get you much more than recommendations tailored to someone else's account. This is a standard design for a high-volume service that can't afford to have every page SSL encrypted.
This utility converts a MIDI file to/from a "human readable" CSV format. http://www.fourmilab.ch/webtools/midicsv/
The string-theoretic meaning of "orbifold" is not the same as its meaning in geometric topology, and according to Wikipedia has "no geometric interpretation". I'm not an expert on the subject but at first glance I'm fairly certain that Tymoczko's orbifold is in the general sense, not the string-theoretic one. Oops?