GPL-compatible does not mean that you can simply copy and paste code willy-nilly into a GPL project.

Most BSD style licenses are unencumbered enough that you can relicense direct derivatives (not just composite works) under practically any terms you want. Commercial companies do this all the time, and it is in fact what makes BSD style licensing for open source software projects so controversial - anyone can create a proprietary fork at will, with components that quickly lose their BSD character as modifications are added.

GPL licensed derivatives of BSD licensed components can be created in the same manner. It is the copyright of the authors of the modifications that makes the relicensing have teeth, it is the lack of a prohibition on additional license terms in BSD style licenses that makes it possible.

The MS-PL, on the other hand, specifically prohibits this practice, much like the Mozilla Public License (MPL). Both are moderate copyleft licenses, designed to make sure that derivatives of covered source files are always available under the terms of the original license.

There is no question that a system like Bedrock allows the ultimate in flexibility in terms of running programs from different distributions and the like. However, a multiple-distribution system like that adds a considerable amount of administrative complexity, making it relatively unlikely to be adopted by non-specialists.

There is an intermediate step that would solve much of the problem here - change the way that Linux packages are packaged and accessed so that multiple versions of library packages can be installed without conflicts, name changes, or repackaging.

The easiest way to do this would be to change the package manager to support a two level namespace instead of a flat one. So instead of simply installing the latest version of the package from your distribution, you could install a (largely) compatible version with the same name from a different source, and the package manager would pull in the necessary libraries from that source (or other ABI compatible sources) and track them as such. As long as the libraries themselves were appropriately versioned, the library packages would install without conflicts.

That wouldn't come close to letting you install any package from any distribution (in some cases the dependencies would be too complicated, or the ABI too different in subtle ways), but it would allow you to install more recent versions of most packages from the newer versions of the same distribution (including beta, rawhide, testing, versions etc) without problems in most cases, and many ABI compatible packages from other distributions as well.

In the 1990s, when Internet access from homes was mostly by dial-up, those lucrative âoetermination fees,â as theyâ(TM)re called, led to a proliferation of Internet service providers

This claim is dubious, to put it mildly. The termination fees were paid to the terminating telephone company. The ISP had nothing to do with it. In some cases this may have allowed CLECs (competitive local exchange carriers) to provide slightly lower rates to independent ISPs, but that is hardly the sort of thing that would lead to a proliferation of ISPs by itself.

The real reason for the proliferation of ISPs is that the phone companies themselves dragged their feet as long as possible on providing anything other than ordinary dialup service. ISP startup costs were relatively low, demand was very high, and at the time ISP service came with all sorts of value added features to allow ISPs to distinguish themselves from their competition.

In addition, if the FCC didn't wildly misread the Communications Act of 1934 at the prompting of the phone companies, there would still be a large number of independent ISPs. Internet access is not an information service, it is a telecommunications service.

UTOPIA is great, if you can get it. The problem is that your city needs to sign on, and you and preferably several of your neighbors need to each agree to pay ~$30 a month to lease a fiber connection (or purchase the the right to use one indefinitely for ~$3000). Then you pay your ISP / IPTV / telco provider to deliver service to you over the shared Ethernet network. Build out has been relatively slow, in part because they originally projected that most customers would sign up for Internet, television, and phone service over the network, where in reality most want just plain Internet service.

Utah is a heavily Republican dominated state, and UTOPIA is certainly not on the Republican hit list. It is mostly on the hit list of lobbyists for CenturyLink (Qwest) and Comcast. They tried to have the state prohibit such networks several years ago and failed. UTOPIA is now a fait accompli and the chances of it being shut down by legislative action are non-existent. They need those revenues to pay the bonds back. The only question is can UTOPIA succeed enough with its new revenue model to make new cities want to sign on. I sure hope so.

I don't know who was the money to buy expensive toys that the manufacturer leaves behind two and a half years later. I guess it is good that someone out there is willing to take the hit.

The problem is that on Windows RT devices, users will not be allowed to disable Secure Boot or provide their own keys. Such devices will be Windows RT only bricks.

You are off by a factor of ten. Process sizes are currently in the 22 - 32 nm range. 0.45 micron (450 nm) would have been close to the state of the art almost twenty years ago.
http://en.wikipedia.org/wiki/22_nanometer

"Some of the commercial airports with asphalt runways include Baltimore-Washington International, Lindbergh Field in San Diego, McCarren International (Las Vegas), Memphis International, Newark International, Oakland International, O'Hare International (Chicago), and San Francisco International."
http://www.moasphalt.org/facts/asphalt/airport_qa.pdf

On the second point, if they were to release all of their hardware specs, then, it's theoretically possible for someone with a bigger budget (Intel comes to mind) to come in, build these exact same chipsets in higher quantities and undercut AMD at sales.

That is ridiculous. The specifications needed to interface with a hardware device are roughly comparable to a complete definition of a software API. The implementation details are typically thousands of times more complicated.

For example, if you had the complete interface specification for a modern desktop microprocessor (freely available, easily a couple of thousand pages), just add several hundred million dollar research and development budget, and you too can produce a compatible device with comparable performance, if you are lucky.

no attempt is offered at explaining why SPDY should be slower than plain ol' HTTP, only why it might not be faster

The author was testing SPDY over TLS, which has a significant connection startup overhead. That probably explains all the performance degradation relative to regular HTTP.

In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason. SPDY+TLS isn't likely to be used for that without _major_ standards modifications to allow third party content to be transparently proxied through first party sites cookies and all.

Let's see if I've got this straight: "You gave me A, B, and C for free yesterday, and now you're only giving me an improved A and B for free?

What would really happen if Microsoft crippled future versions of Visual Studio Express is that a market would be created for low or no cost alternatives. That would probably be a good thing but it would be annoying for many people to convert. It probably wouldn't be too hard to port KDevelop to Windows, for example.

Have you considered that the economics of the support business change dramatically depending on how many million customers you have?

The question was not about support, but bug fixing.

For most mid-range and custom business software, fixes to anything but the most serious bugs (and often not even then) only come with a support contract. A support contract is typically both how you get bug fix releases and reasonable attention to the bugs that you would like to have fixed.

Google only paid $74k in tax on the multiple billions which Australian people and companies paid to them for services provided in Australia.

That is a function of the tax laws. The only reliable way to generate tax revenue on services provided by a foreign company is to charge a goods and services tax on purchases of those services. If the GST was not included in those figures, they are misleading. If the GST applied and was not collected, it should have been. If the GST does not apply, perhaps the powers that be should think about changing that.

It is unreasonable to expect to collect corporate income taxes from corporations that are not actually domiciled in the taxing entity. Legally speaking, it is essentially impossible. Tariffs and GSTs are about the only options.

The main problem with having thirteen months is that it is not evenly divisible into halves, quarters, thirds, etc. That results in scheduling difficulties for a lot of things.

That is probably a livable deficiency, given the other advantages though. It is much cleaner than having intercalary weeks every so many years. The proposal referred to in the original post is a scheduling, accounting, budgeting, and billing disaster.