Perhaps they used the author's home address for the map location when available? The data for southern Germany seems a bit strange, too. And the interactive map is rather crappy: no legend, no proper zooming, no apparent way to access the raw data associated with the points.
So by this explanation I can link my closed-sourced program to a GPL library(dynamically). I only use it's headers!
Yes, Stallman's position is somewhat inconsistent. He also claims that you must not reference to your pre-existing OpenSSL library install from GPLed software (without certain linking exceptions). This particular licensing conflict would not arise if mere reference did not create derivative works. I'm pretty sure that Stallman meant that only header files (or interface definitions) for well-published, standardized programming interfaces (such as POSIX, OpenGL, or the Java SE class library) are not subject to copyright law. In other cases, merely referencing a work causes its license to apply to your work, unless the license says otherwise.
In my opinion, Stallman, and by extension, the FSF, have lost some perspective: they promote very draconian interpretations of copyright law, with the goal of strengthening the GPL and its protections against software hoarders ("copyleft"). As a side effect, these interpretations create issues for anyone who deals with software outside the GNU ecosystem. With the push to the Affero GPL, everyone needs to worry about licensing again, even if they do not distribute anything in the traditional sense. This is a step back, and begins to restrict user freedom.
Rhode Island recognizes common law marriage. Assuming that it was a common law arriage, hasn't the accused a reasonable expectation to be divorced after unfriending his wife on Facebook, and generally stopping interacting with her?
Ask people who want to marry, but are not allowed to. It's close to impossible to give a long-term unmarried relationship the same legal status as a marriage (workarounds like power of attorney tend to not as reliable).
Hasn't the federal government got a black budget to fund operations which are unpopular and of questionable legality? Why can't the inmates be moved out in the same way they where moved in?
How do you port something that entirely depends on access to the underlying native APIs to an environment whose whole purpose is to keep you away from the native API? As so far as not even have a native programming layer.
Perhaps using C++/CIL? It certainly needs quite a bit porting. (And Qt is not tied to OpenGL.)
So Nokia could say, "we will not commit resources to a WP7 port, but will happily include a community-provided one", with full knowledge that it is quite unlikely to happen, ever. Sends a much better message to the community.
Qt is free software. How can Nokia prevent ports to platforms such as Windows Phone 7? They can refuse to make it part of an official Nokia-backed Qt release, but they cannot prevent the port from happening.
On the other hand, there don't seem to be many external contributions to Qt, so such ports seem rather unlikely.
GPLv3 is still compatible with the App Store if you stipulate that you run the application on behalf of Apple, which does not seem to be that far off from reality:
You may convey covered works to others for the sole purpose of having them [...] provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus [...] running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
At the very least, the clause is extremely ambiguous. At worst, it completely destroys the effectiveness of the GPLv3 as a copyleft license. (A lot depends on the interpretation what it means to "control copyright".)
Even in Europe, you can believe what you want. Publicly denying the holocaust might result in fines. If you do it to instigate hatred, you might do some jail time, too.
Java updates contain unrelated bugfixes and functionality, breaking applications. They are far from being minimal updates. Back in the Sun days, this was addressed by enabling parallel installation of many JVM versions. It was even possible for web content to request a specific JVM version, which means that you actually had to update to a newer version and delete all the old versions. I'm not complete sure that this part has actually been addressed. It's certainly a problem for those who still need to use Java 1.4 or Java 5 (which are out of security support now, but are still widely mandated in the industry).
Propagation generally happens via applets, loaded through IFRAMEs or Javascript-based redirects. Actual payloads are not yet OS-agnostic (even though the exploits themselves are).
Which development branch? B's? You do realise that since git is distributed, A's and B's and the master upstream repositories are three completely distinct repositories.
Most projects (even non-corporate ones) have a shared, centralized repository to which more than person can push, so the push attribution problem arises.
One reason for centralized repositories is that you cannot have decentralized deployment. Your organization has only got one www.example.org server (cluster), so eventually, there is a very strong constraint which linearizes development. Certain build and testing infrastructure also strongly favors linearity.
First of all, non-fast-forward pushes are not allowed by default.
After the merge, it is a fast-forward push, and the server cannot distinguish it from new, legitimate development. The problem is not that Git doesn't prevent the push (after all, you need to be able to get new commits into the repository). The problem is that out of the box, Git does not keep track of who pushes what. Out of band solutions exist, and those hosters typically provide that.
You're wrong. I found the hardware description in the paper (finally):
We run experiments on a 48-core machine, with a Tyan Thunder S4985 board and an M4985 quad CPU daughter-board. The machine has a total of eight 2.4 GHz 6-core AMD Opteron 8431 chips. Each core has private 64 Kbyte instruction and data caches, and a 512 Kbyte private L2 cache. The cores on each chip share a 6 Mbyte L3 cache, 1 Mbyte of which is used for the HT Assist probe filter [7]. Each chip has 8 Gbyte of local off-chip DRAM
This is a NUMA machine, so their testing methodology involving tmpfs is totally bogus because it artificially increases inter-node memory traffic. Furthermore, it is unlikely that the results apply to the non-NUMA, single-chip 48-core architecture you have in mind.
Developers can push arbitrary data and metadata into the repository. The standard server does not map branch updates to user accounts. Here's an example: Suppose developer A merges the master branch into a development branch (which is not ready for merging into the master). Git will record a merge commit, attributed to developer A. Developer B then accidentally pushes the development branch onto the master. This is now a fast-forward merge, so no additional commit will be created, and the mistake is not attributable to developer B (and it will look like developer A's mistake, because their commit will appear at the tip).
In some (mostly corporate?) environments, this can be a problem. This is something which can be fixed with additional bookkeeping on the server side and out-of-band user interface. I believe most of the Git hosting platforms out there have this functionality, and they keep it proprietary to them.
One SGI Altix version comes with 2,048 cores running a single image.
The benchmarks in the paper are a bit suspicious because they avoid disk I/O. tmpfs is used instead, which may skew results significantly. Surprisingly, they do not describe the architecture of the test machine, but perhaps I've missed that. They suggest that a workload which does not spend much time in the kernel cannot have scaling issues caused by the kernel, which seems rather dubious to me.
The official FSF position was that they could take the code and release it under the LGPL. They thought that the license was structured in such a way that it basically lost its force once the covered software was built into another piece of software. I'm not sure if they have ever stated that analysis publicly.
Sometimes, I wish they would take this pragmatic approach towards the 4-clause BSD license.
But there's a reason why the copyright headers are missing in that PDF---they say that this code is under University of California copyright, so both System V and GNU/Linux copied it.
It's not from BSD: ELF in itself first appeared in AT&T V.AT&T V is a curious way of referring to System V, BSD's main rival among the several UNIX streams back then.
Two things make those numbers fairly irrelevant: CDNs are optimized for delivering content to end users, not datacenters (where most machines are non-Windows anyway, so you don't even need AV updates). And what matters in the end aren't ping times, but actual request latency.
Slashdot Mirror
But they could, especially with PoE+. Essentially, they're just rebuilding technology which is already available commercially.
Perhaps they used the author's home address for the map location when available? The data for southern Germany seems a bit strange, too. And the interactive map is rather crappy: no legend, no proper zooming, no apparent way to access the raw data associated with the points.
So by this explanation I can link my closed-sourced program to a GPL library(dynamically). I only use it's headers!
Yes, Stallman's position is somewhat inconsistent. He also claims that you must not reference to your pre-existing OpenSSL library install from GPLed software (without certain linking exceptions). This particular licensing conflict would not arise if mere reference did not create derivative works. I'm pretty sure that Stallman meant that only header files (or interface definitions) for well-published, standardized programming interfaces (such as POSIX, OpenGL, or the Java SE class library) are not subject to copyright law. In other cases, merely referencing a work causes its license to apply to your work, unless the license says otherwise.
In my opinion, Stallman, and by extension, the FSF, have lost some perspective: they promote very draconian interpretations of copyright law, with the goal of strengthening the GPL and its protections against software hoarders ("copyleft"). As a side effect, these interpretations create issues for anyone who deals with software outside the GNU ecosystem. With the push to the Affero GPL, everyone needs to worry about licensing again, even if they do not distribute anything in the traditional sense. This is a step back, and begins to restrict user freedom.
Rhode Island recognizes common law marriage. Assuming that it was a common law arriage, hasn't the accused a reasonable expectation to be divorced after unfriending his wife on Facebook, and generally stopping interacting with her?
Ask people who want to marry, but are not allowed to. It's close to impossible to give a long-term unmarried relationship the same legal status as a marriage (workarounds like power of attorney tend to not as reliable).
Hasn't the federal government got a black budget to fund operations which are unpopular and of questionable legality? Why can't the inmates be moved out in the same way they where moved in?
How do you port something that entirely depends on access to the underlying native APIs to an environment whose whole purpose is to keep you away from the native API? As so far as not even have a native programming layer.
Perhaps using C++/CIL? It certainly needs quite a bit porting. (And Qt is not tied to OpenGL.)
So Nokia could say, "we will not commit resources to a WP7 port, but will happily include a community-provided one", with full knowledge that it is quite unlikely to happen, ever. Sends a much better message to the community.
Qt is free software. How can Nokia prevent ports to platforms such as Windows Phone 7? They can refuse to make it part of an official Nokia-backed Qt release, but they cannot prevent the port from happening.
On the other hand, there don't seem to be many external contributions to Qt, so such ports seem rather unlikely.
Are these incidents only self-reported? How would a pilot tell a short visual hallucination from a laser pointer "strike"?
There is not enough entropy in credit card numbers to make hashing a serious obstacle.
GPLv3 is still compatible with the App Store if you stipulate that you run the application on behalf of Apple, which does not seem to be that far off from reality:
At the very least, the clause is extremely ambiguous. At worst, it completely destroys the effectiveness of the GPLv3 as a copyleft license. (A lot depends on the interpretation what it means to "control copyright".)
Even in Europe, you can believe what you want. Publicly denying the holocaust might result in fines. If you do it to instigate hatred, you might do some jail time, too.
Java updates contain unrelated bugfixes and functionality, breaking applications. They are far from being minimal updates. Back in the Sun days, this was addressed by enabling parallel installation of many JVM versions. It was even possible for web content to request a specific JVM version, which means that you actually had to update to a newer version and delete all the old versions. I'm not complete sure that this part has actually been addressed. It's certainly a problem for those who still need to use Java 1.4 or Java 5 (which are out of security support now, but are still widely mandated in the industry).
Propagation generally happens via applets, loaded through IFRAMEs or Javascript-based redirects. Actual payloads are not yet OS-agnostic (even though the exploits themselves are).
Most projects (even non-corporate ones) have a shared, centralized repository to which more than person can push, so the push attribution problem arises.
One reason for centralized repositories is that you cannot have decentralized deployment. Your organization has only got one www.example.org server (cluster), so eventually, there is a very strong constraint which linearizes development. Certain build and testing infrastructure also strongly favors linearity.
After the merge, it is a fast-forward push, and the server cannot distinguish it from new, legitimate development. The problem is not that Git doesn't prevent the push (after all, you need to be able to get new commits into the repository). The problem is that out of the box, Git does not keep track of who pushes what. Out of band solutions exist, and those hosters typically provide that.
You're wrong. I found the hardware description in the paper (finally):
This is a NUMA machine, so their testing methodology involving tmpfs is totally bogus because it artificially increases inter-node memory traffic. Furthermore, it is unlikely that the results apply to the non-NUMA, single-chip 48-core architecture you have in mind.
Developers can push arbitrary data and metadata into the repository. The standard server does not map branch updates to user accounts. Here's an example: Suppose developer A merges the master branch into a development branch (which is not ready for merging into the master). Git will record a merge commit, attributed to developer A. Developer B then accidentally pushes the development branch onto the master. This is now a fast-forward merge, so no additional commit will be created, and the mistake is not attributable to developer B (and it will look like developer A's mistake, because their commit will appear at the tip).
In some (mostly corporate?) environments, this can be a problem. This is something which can be fixed with additional bookkeeping on the server side and out-of-band user interface. I believe most of the Git hosting platforms out there have this functionality, and they keep it proprietary to them.
One SGI Altix version comes with 2,048 cores running a single image.
The benchmarks in the paper are a bit suspicious because they avoid disk I/O. tmpfs is used instead, which may skew results significantly. Surprisingly, they do not describe the architecture of the test machine, but perhaps I've missed that. They suggest that a workload which does not spend much time in the kernel cannot have scaling issues caused by the kernel, which seems rather dubious to me.
This seems to be a reinvention of field calls, with a slightly different purpose.
The official FSF position was that they could take the code and release it under the LGPL. They thought that the license was structured in such a way that it basically lost its force once the covered software was built into another piece of software. I'm not sure if they have ever stated that analysis publicly.
Sometimes, I wish they would take this pragmatic approach towards the 4-clause BSD license.
For example, this is a posting using the code name: http://communities.intel.com/message/51359;jsessionid=F3036FCC8C1DD878FCED25A7A6D32547.node6COM
Can this really happen easily? I thought for really ugly things to happen, you need to have switches (without working STP, that is).
There are some actual similarities beyond API necessities. This PDF contains a striking example of that:
http://www.mcbride-law.com/wp-content/uploads/2010/07/Tab-247.pdf
But there's a reason why the copyright headers are missing in that PDF---they say that this code is under University of California copyright, so both System V and GNU/Linux copied it.
It's not from BSD: ELF in itself first appeared in AT&T V. AT&T V is a curious way of referring to System V, BSD's main rival among the several UNIX streams back then.
Two things make those numbers fairly irrelevant: CDNs are optimized for delivering content to end users, not datacenters (where most machines are non-Windows anyway, so you don't even need AV updates). And what matters in the end aren't ping times, but actual request latency.