"FP" means "Functional Programming," not "Function-level Programming Language." It refers to a class of programming techniques, as well as to a type of programming language particularly suitable for applying those techniques. John Backus' Turing lecture on FP was a key inspiration for my own dissertation, as well as for a lot of work in Scheme, Haskell, and a host of other projects.
I see that others have already addressed some of the other foolishness in the lead article as well as the replies. John Backus was an outstandingly careful and insightful thinker, with a deep understanding of the difference between progress in a line of work and completion of that work. I don't care any more than I think he would have about an appearance of disrespect or lack of appreciation. But I encourage those who reacted superficially to the obituary to look more deeply into Backus' work, and use it as a model of effective thinking.
That includes the writer of the lead article. I read Slashdot first, because it so often provides a better introduction to the news than the New York Times. In this case, Slashdot fell down badly on the job.
Under the Constitution he has the power ONLY if there is a rebellion or invasion. In only ONE case in all of US History has it been suspended, and that was during the Civil war due to rebellion.
I dug out my old Summaries of Leading Cases on the Constitution, Paul C. Barhtolomew, Littlefield, Adams and Company, Totowa NJ, 8th edition 1973. Ex parte Merryman, 17 Fed. Cas. No. 9487 (1861 is worth quoting in full. It arose from President Lincoln's attempt to suspend habeas corpus during the rebellion of southern states in the war between the states:
"The petitioner, a citizen of Baltimore, was arrested by a military officer acting on the authority of his commanding officer. The petitioner was accused of treason against the United States. The Chief Justice of the Supreme Court, while on Circuit Court duty, issued a writ of habeas corpus directing the commanding officer to deliver the prisoner, and this was refused on the grounds that the officer was authorized by the President to suspend the writ.
Opinion by Mr. Chief Justice Taney while on Circuit Court duty
Question---Can the President suspend the writ of habeas corpus?
Decision---No.
Reason---The Court held that the petitioner was entitled to be set free on the grounds that (1) the President, under the Constitution cannot suspend the writ of habeas corpus. This can be done under the Constitution only by Congress, since the provision appears in the Article of the Constitution dealing with Congress, and in a list of limitations on Congress. (2) A military officer cannot arreest a person not subject to the rules and articles of war, except in the aid of civil authority when the individual has committed an offense against the United States. In such a case the military officer must deliver the prisoner immediately to civil authority, to be dealt with according to law."
I wish that every citizen of the USA would keep this book on a shelf, and refer to it. Ex parte Merryman has never been overturned by another decision. The US government has violated the Constitution, as read by the Supreme Court in 1861, in many ways. The President has vacated habeas corpus on his own, without Constitutional authority. The congress has suspended habeas corpus without a case of rebellion or invasion in the US. Prisoners of many sorts---those in Afghan and Iraqi prisons, those at Guantanamo, several in military prisons in the US, and others who have been captured (e.g. while changing planes in the US) and sent to imprisonment in other nations---have neither been subject to "the rules and articles of war," nor delivered "immediately to civil authority."
I am not a lawyer, but I have some direct experience as an expert witness in two court cases dealing with research tax credits, and I have read a third decision closely. The tax law already allows corporations to take a tax credit for expenses associated with research (not, to my knowledge, with development). A tax credit is much more valuable than a deduction---it means that 100% of the expense is recovered from reduced taxes.
There appears to be a lot of confusion about precisely what sort of software develoment qualifies as research. The tax law has been interpreted to require that research eligible for the credit must involve a "process of experimentation," and must "expand or refine" the principles of the relevant field. In my opinion, the expansion or refinement doesn't need to be large or deep---a lot less than a Ph.D. dissertation. But a few bug fixes, or a simple port to a different language or architecture might not qualify.
In my opinion (completely unauthoritative, unless I get called as a witness again), work contributed to free software projects has a better chance to qualify for the credit than much of the proprietary work that I have seen.
This is a good time to look at Bob Frankston's dotDNS proposal for a layer of reliable but meaningless domain names. dotDNS lookups can be made self-verifiable using public-key signatures, but without the costly chain of trust required by DNSSEC methods. The validity of a dotDNS binding can be verified easily by the querier, without relying at all on the server that provided the putative binding.
dotDNS does not solve the whole problem, since any layer that translates from humanly meaningful names to dotDNS names is still vulnerable to hijacking. But the reliable and verifiable name bindings in dotDNS will make it *much* easier to switch name-resolution services when we are dissatisfied with their policies.
dotDNS is a cheap and immediately deployable positive step toward fixing the DNS mess, requiring no approval by any central agency. It's time for a visionary sponsor to step forward and just do it.
I haven't yet seen a TCO study that includes the risk of a BSA audit in a Windows shop. The TCO for running Windows should include the cost of insurance against the disruption of a BSA audit and the penalties paid for apparently unlicensed software.
The basic idea of a short-hop forwarded wireless network is excellent, and arguably even essential for the continued health of the Internet. It calls for peer co-operation by individuals of the same sort that was applied by universities and research institutions when the Internet broke loose from ARPANet.
Everyone interested in this topic should read Kevin Werbach's Open Spectrum proposal, which has already been posted on Slashdot.
The network design and implementation problems are surely soluble, but haven't been thoroughly addressed yet. The key problem is how to start a deployment. It requires some critical mass of users to create a local system that provides a model for further deployment. Here's a possible scenario:
A volunteer local wireless network using fixed-station point-to-point communications implements a more general protocol suitable for mobile stations.
A few public-minded geeks slip an implementation of the protocol into the system for a hand-held computer. It doesn't need to be the most popular hand-held, it just needs to have a sufficient following to get noticed.
Other local wireless network organizations copy the method, including amateur groups, universities, and businesses that use it to attract customers to buy other goods and services.
It doesn't matter how fast such a thing spreads, and it can be very valuable even if it doesn't completetly replace more concentrated connections.
Here is the letter that I sent to DOJ. Consider it GPLed, and use it in any way you find productive.
Mike O'Donnell
Date: Wed, 23 Jan 2002 18:10:54 CST
To: microsoft.atr@usdoj.gov
Subject: Microsoft Settlement
Date: Wed, 23 Jan 2002 18:10:54 -0600
From: "Mike O'Donnell"
Renata B. Hesse
Antitrust Division
U.S. Department of Justice
601 D Street NW
Suite 1200
Washington, DC 20530-0001
Dear Ms. Hesse:
I would like to comment on the proposed Final Judgment in United
States v. Microsoft, as provided in the Tunney Act.
I find that the proposed judgment is insufficient by a large margin to
restore healthy competition in the computer operating systems and
software application markets, so it is not in the public interest and
should not be affirmed by the court.
The proposed Final Judgment attempts to remedy Microsoft's established
illegal anticompetitive practices by prohibiting particular forms of
conduct involving overly restrictive licensing terms, terms that vary
in order to reward those who accept and punish those who contest a
Microsoft monopoly, and terms that make switching to competing
products more difficult or more costly. It also prohibits certain
forms of retaliation against OEMs who support products competing with
Microsoft's products. It also requires Microsoft to disclose APIs and
communication protocols for its products under certain circumstances
and for certain purposes.
It is inherently difficult, and perhaps impossible, to remedy
Microsoft's particular forms of illegal anticompetitive behavior
through conduct remedies. Both the underlying concepts in which
conduct remedies are defined, and the particular anticompetitive
techniques used by Microsoft change far too rapidly, and Microsoft
itself has far too much influence on those changes, for them to serve
in the foundation of effective conduct remedies.
The remedies in the proposed judgment refer to concepts of "API,"
"operating system," "middleware," "application," "platform software,"
"top-level window," "interface elements," "icons," "shortcuts," "menu
entries." The definitions of these concepts are not robust and
timeless. Compared to concepts in other branches of business and
engineering they are relatively ephemeral, controversial, dependent on
rapidly changing technological context, and subject to deliberate
manipulation by Microsoft. For example, an "operating system" in the
1960s was a software system to organize the basic functionality of a
computer, and it contained little or no user interface code. In the
1970s "operating systems" often contained substantial collections of
utility applications and rudimentary interactive user interfaces
called "shells." In the 1980s, the X Window system was created as a
form of what is now called "middleware" to provide a graphical
interactive user interface, used widely in conjunction with Unix
operating systems. Apple and Microsoft created similar graphical
interactive user interfaces, but defined them to be parts of their
operating systems, rather than additional middleware. In the near
future, distributed and network computing are likely to make it quite
difficult to determine the boundaries of a single operating system. In
the past, Microsoft appears to have deliberately manipulated the
boundaries of such conceptual categories to create and preserve a
monopoly position, and I expect it to continue such practices in the
future. The proposed judgment provides definitions that narrow these
already problematic concepts even further, making them even more
vulnerable to deterioration due to technological change and to
manipulation by Microsoft.
Furthermore, the particular conduct requirements in the proposed
judgment are far too narrow. Every one of the requirements is weak in
some way. For example, consider the requirement to "disclose to ISVs,
IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating
with a Windows Operating System Product,... the APIs and related
Documentation that are used by Microsoft Middleware to interoperate
with a Windows Operating System Product." Microsoft and other software
vendors like to treat their Applications Product Interfaces (API) as
intellectual property. But in good engineering practice these are key
parts of the warrantable specifications of a product. This holds in
particular for operating systems and middleware, which by their nature
are especially intended for, suitable for, and often useless without
interaction with other software products. APIs define the quality of
that interaction, but they do not provide it. The implementation of an
API in program code (which is naturally protected by trade secret,
copyright, and patent law) provides the quality of interaction
defined by an API. Without access to the complete API, the licensor of
an operating system cannot employ the system freely in the way that
good software engineering practice suggests. With complete public
access to an API, a software company may still protect its
implementation of the API, which contains the real value that it has
created. Keeping an API secret does not correspond to keeping the
inner workings of a product secret. Rather, it corresponds to keeping
the precise function accomplished by that product secret.
So the public interest calls for the widest possible dissemination of
API documentation. But the proposed judgment explicitly calls for
disclosure of APIs "for the sole purpose of interoperating with a
Windows Operating System Product," and only the "APIS and related
Documentation that are used by Microsoft Middleware to interoperate
with a Windows Operating System Product." This excludes the use of
information about the API to provide competitive platforms for running
Windows-compatible software. Keep in mind that Windows-compatible
software does not necessarily come from Microsoft. Microsoft benefits
from the value added to its operating system products by a large
number of less powerful software houses that create Windows-compatible
software. By holding the Windows operating system API secret,
Microsoft in effect keeps crucial information about other companies'
software applications secret, denying those applications the value
added by competing operating systems on which they may run.
Compare the Windows market (and the preceding DOS market) to the
Unix/Linux/Posix market. Microsoft uses secret and changeable APIs to
effectively eliminate competition to provide alternative operating
systems running Windows applications. A competing operating system
must use different APIs, and therefore cannot support all of the same
applications. By contrast, the Posix standard is a completely public
API for Unix/Linux. Various companies, such as Sun Microsystems,
compete to provide different implementations of the Posix
API. Consumers may run Unix/Linux applications on any of these
operating systems.
Similarly, in the hardware market for processors, the specification of
the x86 instruction set architecture (the hardware analog to a
software API), is public. As a result, AMD competes with Intel to
implement that architecture, with immense benefit to the public
interest. Similar publication of standards in the overall
functionality of personal computers led to the immensely beneficial
competition among makers of IBM-compatible PCs. The failure to
disclose Windows operating system APIs destroys the possibility of
similarly beneficial competition among vendors of operating systems.
Very similar considerations to those raised above for APIs apply to
communication protocols (for which the proposed judgment provides
limited disclosure) and to file formats (not covered in the proposed
judgment). Note that Adobe made full public disclosure of its
PostScript and PDF formats, compared to Microsoft's secrecy regarding
Word formats, and that this disclosure served the public interest
immensely by promoting the wide availability of PostScript and PDF
printers and viewers.
There are many other detailed shortcomings of the proposed Final
Judgment, including the remaining conduct restrictions and the
enforcement methods. I expect that other correspondents will treat
some of them.
Sincerely yours,
Michael J. O'Donnell
Professor in Computer Science and the Physical Sciences Collegiate Division
The University of Chicago
Senior Fellow in the Computation Institute of
The University of Chicago and Argonne National Laboratory
I teach CS, and I see at least two related but separate things that we usually miss in classes with software projects:
fitting class work into a larger context of code;
collaborating on the software.
Each of these can be addressed by assigning work in definite teams, or by other sorts of interaction. There are at least two obstacles that limit the amount of interaction we allow in class:
many instructors don't have much experience with useful interaction on software;
a lot of extra work is required to define and supervise interaction, and universities almost never reward that extra work.
For some sorts of classes, I've found that I can allow unlimited collaboration, and then evaluate each student based on a private interview in which she presents project work. I evaluate the insight shown in the presentation, rather than whether the student presents her own work or others'. This is very effective in cases where the project work leads to a deeper understanding of the material, rather than merely demonstrating understanding derived from books and lectures. It flops miserably with students who are extremely shy, or who cannot express themselves verbally, but I don't get very many of them.
I have never yet specifically assigned students to work as teams on these projects, but I've allowed them to form teams if they like, and to share work as much as they like. I think that the ability to discuss work completely freely, and to share pieces of code, has helped a lot. But to my surprise, in more than 5 years no students have actually formed a team.
In his novel, The Joke, Milan Kundera traces the treatment of a joke by the communist government of Czechoslovakia. I recommend it to readers interested in the Scientology affair.
Prof. James Freeman at Cornell College in Mount Vernon Iowa put the Iowa state code online. He argues, convincingly in my opinion, that it's important to provide information as plain old HTML files whenever possible, and minimize dynamic page creation.
Several years ago my son, then 14 years old, took a summer course in genetics. The class performed recombinant DNA experiments on E-coli. The chemicals came from grocery-store shelves. The most sophisticated piece of equipment was the temperature control for growing the culture. I expect you could whip one up from a yogurt maker. The first step was to make the culture resistant to pennicilin (since that's so easy to test). The most difficult raw material to acquire was the starting culture of E-coli, already engineered so that it would not thrive in the human gut. I find this a bit scary.
Slashdot Mirror
> Man-in-the-middle attacks were dead easy.
In Alexandre Dumas' The Count of Monte Cristo, the climax of the Count's revenge uses a man-in-the-middle attack on the French telegraph system.
"FP" means "Functional Programming," not "Function-level Programming Language." It refers to a class of programming techniques, as well as to a type of programming language particularly suitable for applying those techniques. John Backus' Turing lecture on FP was a key inspiration for my own dissertation, as well as for a lot of work in Scheme, Haskell, and a host of other projects.
I see that others have already addressed some of the other foolishness in the lead article as well as the replies. John Backus was an outstandingly careful and insightful thinker, with a deep understanding of the difference between progress in a line of work and completion of that work. I don't care any more than I think he would have about an appearance of disrespect or lack of appreciation. But I encourage those who reacted superficially to the obituary to look more deeply into Backus' work, and use it as a model of effective thinking.
That includes the writer of the lead article. I read Slashdot first, because it so often provides a better introduction to the news than the New York Times. In this case, Slashdot fell down badly on the job.
But the president does have the power to do it.
Under the Constitution he has the power ONLY if there is a rebellion or invasion. In only ONE case in all of US History has it been suspended, and that was during the Civil war due to rebellion.
I dug out my old Summaries of Leading Cases on the Constitution, Paul C. Barhtolomew, Littlefield, Adams and Company, Totowa NJ, 8th edition 1973. Ex parte Merryman, 17 Fed. Cas. No. 9487 (1861 is worth quoting in full. It arose from President Lincoln's attempt to suspend habeas corpus during the rebellion of southern states in the war between the states:
"The petitioner, a citizen of Baltimore, was arrested by a military officer acting on the authority of his commanding officer. The petitioner was accused of treason against the United States. The Chief Justice of the Supreme Court, while on Circuit Court duty, issued a writ of habeas corpus directing the commanding officer to deliver the prisoner, and this was refused on the grounds that the officer was authorized by the President to suspend the writ.
Opinion by Mr. Chief Justice Taney while on Circuit Court dutyQuestion---Can the President suspend the writ of habeas corpus?
Decision---No.Reason---The Court held that the petitioner was entitled to be set free on the grounds that (1) the President, under the Constitution cannot suspend the writ of habeas corpus. This can be done under the Constitution only by Congress, since the provision appears in the Article of the Constitution dealing with Congress, and in a list of limitations on Congress. (2) A military officer cannot arreest a person not subject to the rules and articles of war, except in the aid of civil authority when the individual has committed an offense against the United States. In such a case the military officer must deliver the prisoner immediately to civil authority, to be dealt with according to law."
I wish that every citizen of the USA would keep this book on a shelf, and refer to it. Ex parte Merryman has never been overturned by another decision. The US government has violated the Constitution, as read by the Supreme Court in 1861, in many ways. The President has vacated habeas corpus on his own, without Constitutional authority. The congress has suspended habeas corpus without a case of rebellion or invasion in the US. Prisoners of many sorts---those in Afghan and Iraqi prisons, those at Guantanamo, several in military prisons in the US, and others who have been captured (e.g. while changing planes in the US) and sent to imprisonment in other nations---have neither been subject to "the rules and articles of war," nor delivered "immediately to civil authority."I am not a lawyer, but I have some direct experience as an expert witness in two court cases dealing with research tax credits, and I have read a third decision closely. The tax law already allows corporations to take a tax credit for expenses associated with research (not, to my knowledge, with development). A tax credit is much more valuable than a deduction---it means that 100% of the expense is recovered from reduced taxes.
There appears to be a lot of confusion about precisely what sort of software develoment qualifies as research. The tax law has been interpreted to require that research eligible for the credit must involve a "process of experimentation," and must "expand or refine" the principles of the relevant field. In my opinion, the expansion or refinement doesn't need to be large or deep---a lot less than a Ph.D. dissertation. But a few bug fixes, or a simple port to a different language or architecture might not qualify.
In my opinion (completely unauthoritative, unless I get called as a witness again), work contributed to free software projects has a better chance to qualify for the credit than much of the proprietary work that I have seen.
This is a good time to look at Bob Frankston's dotDNS proposal for a layer of reliable but meaningless domain names. dotDNS lookups can be made self-verifiable using public-key signatures, but without the costly chain of trust required by DNSSEC methods. The validity of a dotDNS binding can be verified easily by the querier, without relying at all on the server that provided the putative binding.
dotDNS does not solve the whole problem, since any layer that translates from humanly meaningful names to dotDNS names is still vulnerable to hijacking. But the reliable and verifiable name bindings in dotDNS will make it *much* easier to switch name-resolution services when we are dissatisfied with their policies.
dotDNS is a cheap and immediately deployable positive step toward fixing the DNS mess, requiring no approval by any central agency. It's time for a visionary sponsor to step forward and just do it.
I haven't yet seen a TCO study that includes the risk of a BSA audit in a Windows shop. The TCO for running Windows should include the cost of insurance against the disruption of a BSA audit and the penalties paid for apparently unlicensed software.
Please don't be discouraged by idiotic replies.
The basic idea of a short-hop forwarded wireless network is excellent, and arguably even essential for the continued health of the Internet. It calls for peer co-operation by individuals of the same sort that was applied by universities and research institutions when the Internet broke loose from ARPANet.
Everyone interested in this topic should read Kevin Werbach's Open Spectrum proposal, which has already been posted on Slashdot.
The network design and implementation problems are surely soluble, but haven't been thoroughly addressed yet. The key problem is how to start a deployment. It requires some critical mass of users to create a local system that provides a model for further deployment. Here's a possible scenario:
- A volunteer local wireless network using fixed-station point-to-point communications implements a more general protocol suitable for mobile stations.
- A few public-minded geeks slip an implementation of the protocol into the system for a hand-held computer. It doesn't need to be the most popular hand-held, it just needs to have a sufficient following to get noticed.
- Other local wireless network organizations copy the method, including amateur groups, universities, and businesses that use it to attract customers to buy other goods and services.
It doesn't matter how fast such a thing spreads, and it can be very valuable even if it doesn't completetly replace more concentrated connections.Here is the letter that I sent to DOJ. Consider it GPLed, and use it in any way you find productive.
... the APIs and related
Mike O'Donnell
Date: Wed, 23 Jan 2002 18:10:54 CST
To: microsoft.atr@usdoj.gov
Subject: Microsoft Settlement
Date: Wed, 23 Jan 2002 18:10:54 -0600
From: "Mike O'Donnell"
Renata B. Hesse
Antitrust Division
U.S. Department of Justice
601 D Street NW
Suite 1200
Washington, DC 20530-0001
Dear Ms. Hesse:
I would like to comment on the proposed Final Judgment in United
States v. Microsoft, as provided in the Tunney Act.
I find that the proposed judgment is insufficient by a large margin to
restore healthy competition in the computer operating systems and
software application markets, so it is not in the public interest and
should not be affirmed by the court.
The proposed Final Judgment attempts to remedy Microsoft's established
illegal anticompetitive practices by prohibiting particular forms of
conduct involving overly restrictive licensing terms, terms that vary
in order to reward those who accept and punish those who contest a
Microsoft monopoly, and terms that make switching to competing
products more difficult or more costly. It also prohibits certain
forms of retaliation against OEMs who support products competing with
Microsoft's products. It also requires Microsoft to disclose APIs and
communication protocols for its products under certain circumstances
and for certain purposes.
It is inherently difficult, and perhaps impossible, to remedy
Microsoft's particular forms of illegal anticompetitive behavior
through conduct remedies. Both the underlying concepts in which
conduct remedies are defined, and the particular anticompetitive
techniques used by Microsoft change far too rapidly, and Microsoft
itself has far too much influence on those changes, for them to serve
in the foundation of effective conduct remedies.
The remedies in the proposed judgment refer to concepts of "API,"
"operating system," "middleware," "application," "platform software,"
"top-level window," "interface elements," "icons," "shortcuts," "menu
entries." The definitions of these concepts are not robust and
timeless. Compared to concepts in other branches of business and
engineering they are relatively ephemeral, controversial, dependent on
rapidly changing technological context, and subject to deliberate
manipulation by Microsoft. For example, an "operating system" in the
1960s was a software system to organize the basic functionality of a
computer, and it contained little or no user interface code. In the
1970s "operating systems" often contained substantial collections of
utility applications and rudimentary interactive user interfaces
called "shells." In the 1980s, the X Window system was created as a
form of what is now called "middleware" to provide a graphical
interactive user interface, used widely in conjunction with Unix
operating systems. Apple and Microsoft created similar graphical
interactive user interfaces, but defined them to be parts of their
operating systems, rather than additional middleware. In the near
future, distributed and network computing are likely to make it quite
difficult to determine the boundaries of a single operating system. In
the past, Microsoft appears to have deliberately manipulated the
boundaries of such conceptual categories to create and preserve a
monopoly position, and I expect it to continue such practices in the
future. The proposed judgment provides definitions that narrow these
already problematic concepts even further, making them even more
vulnerable to deterioration due to technological change and to
manipulation by Microsoft.
Furthermore, the particular conduct requirements in the proposed
judgment are far too narrow. Every one of the requirements is weak in
some way. For example, consider the requirement to "disclose to ISVs,
IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating
with a Windows Operating System Product,
Documentation that are used by Microsoft Middleware to interoperate
with a Windows Operating System Product." Microsoft and other software
vendors like to treat their Applications Product Interfaces (API) as
intellectual property. But in good engineering practice these are key
parts of the warrantable specifications of a product. This holds in
particular for operating systems and middleware, which by their nature
are especially intended for, suitable for, and often useless without
interaction with other software products. APIs define the quality of
that interaction, but they do not provide it. The implementation of an
API in program code (which is naturally protected by trade secret,
copyright, and patent law) provides the quality of interaction
defined by an API. Without access to the complete API, the licensor of
an operating system cannot employ the system freely in the way that
good software engineering practice suggests. With complete public
access to an API, a software company may still protect its
implementation of the API, which contains the real value that it has
created. Keeping an API secret does not correspond to keeping the
inner workings of a product secret. Rather, it corresponds to keeping
the precise function accomplished by that product secret.
So the public interest calls for the widest possible dissemination of
API documentation. But the proposed judgment explicitly calls for
disclosure of APIs "for the sole purpose of interoperating with a
Windows Operating System Product," and only the "APIS and related
Documentation that are used by Microsoft Middleware to interoperate
with a Windows Operating System Product." This excludes the use of
information about the API to provide competitive platforms for running
Windows-compatible software. Keep in mind that Windows-compatible
software does not necessarily come from Microsoft. Microsoft benefits
from the value added to its operating system products by a large
number of less powerful software houses that create Windows-compatible
software. By holding the Windows operating system API secret,
Microsoft in effect keeps crucial information about other companies'
software applications secret, denying those applications the value
added by competing operating systems on which they may run.
Compare the Windows market (and the preceding DOS market) to the
Unix/Linux/Posix market. Microsoft uses secret and changeable APIs to
effectively eliminate competition to provide alternative operating
systems running Windows applications. A competing operating system
must use different APIs, and therefore cannot support all of the same
applications. By contrast, the Posix standard is a completely public
API for Unix/Linux. Various companies, such as Sun Microsystems,
compete to provide different implementations of the Posix
API. Consumers may run Unix/Linux applications on any of these
operating systems.
Similarly, in the hardware market for processors, the specification of
the x86 instruction set architecture (the hardware analog to a
software API), is public. As a result, AMD competes with Intel to
implement that architecture, with immense benefit to the public
interest. Similar publication of standards in the overall
functionality of personal computers led to the immensely beneficial
competition among makers of IBM-compatible PCs. The failure to
disclose Windows operating system APIs destroys the possibility of
similarly beneficial competition among vendors of operating systems.
Very similar considerations to those raised above for APIs apply to
communication protocols (for which the proposed judgment provides
limited disclosure) and to file formats (not covered in the proposed
judgment). Note that Adobe made full public disclosure of its
PostScript and PDF formats, compared to Microsoft's secrecy regarding
Word formats, and that this disclosure served the public interest
immensely by promoting the wide availability of PostScript and PDF
printers and viewers.
There are many other detailed shortcomings of the proposed Final
Judgment, including the remaining conduct restrictions and the
enforcement methods. I expect that other correspondents will treat
some of them.
Sincerely yours,
Michael J. O'Donnell
Professor in Computer Science and the Physical Sciences Collegiate Division
The University of Chicago
Senior Fellow in the Computation Institute of
The University of Chicago and Argonne National Laboratory
I teach CS, and I see at least two related but separate things that we usually miss in classes with software projects:
- fitting class work into a larger context of code;
- collaborating on the software.
Each of these can be addressed by assigning work in definite teams, or by other sorts of interaction. There are at least two obstacles that limit the amount of interaction we allow in class:For some sorts of classes, I've found that I can allow unlimited collaboration, and then evaluate each student based on a private interview in which she presents project work. I evaluate the insight shown in the presentation, rather than whether the student presents her own work or others'. This is very effective in cases where the project work leads to a deeper understanding of the material, rather than merely demonstrating understanding derived from books and lectures. It flops miserably with students who are extremely shy, or who cannot express themselves verbally, but I don't get very many of them.
I have never yet specifically assigned students to work as teams on these projects, but I've allowed them to form teams if they like, and to share work as much as they like. I think that the ability to discuss work completely freely, and to share pieces of code, has helped a lot. But to my surprise, in more than 5 years no students have actually formed a team.
Mike O'D.U. Chicago
In his novel, The Joke, Milan Kundera traces the treatment of a joke by the communist government of Czechoslovakia. I recommend it to readers interested in the Scientology affair.
Prof. James Freeman at Cornell College in Mount Vernon Iowa put the Iowa state code online. He argues, convincingly in my opinion, that it's important to provide information as plain old HTML files whenever possible, and minimize dynamic page creation.
For general good advice on Web publishing, I like Philip and Alex's Guide to Web Publishing .
Mike O'Donnell
I have Telocity in Chicago. They have been mostly very good. Installation was almost on time. Good points:
- Static IP address.
- No stupid restrictions. I'm encouraged to run Apache if I want to, masquerade a LAN, etc.
- No starting cost, and no minimum contract duration.
- Very little network congestion due to the ISP.
Bad points:- They still haven't produced multiple IP addresses.
- The installer came when I was away, and cannibalized a voice line that I intended to continue using.
- Occasional very long down times---most of a day in one case.
- It takes them a long time to post clear and useful information about the cause of down time.
- Frequent short loss of synchronization (often correlated with electrical storms, which have been frequent in the late part of this summer).
On the whole, I'm happy.Several years ago my son, then 14 years old, took a summer course in genetics. The class performed recombinant DNA experiments on E-coli. The chemicals came from grocery-store shelves. The most sophisticated piece of equipment was the temperature control for growing the culture. I expect you could whip one up from a yogurt maker. The first step was to make the culture resistant to pennicilin (since that's so easy to test). The most difficult raw material to acquire was the starting culture of E-coli, already engineered so that it would not thrive in the human gut. I find this a bit scary.