Why continue with the concept of name ownership at all? It should be technically impossible to own a name, in the same way that it should be impossible to monopolize ideas.
Let people and entities use whatever name they want; the remaining problem is to verify that you are talking to the right host, but you should need to do that anyway. Invariably, any sort of central authority can and will be subverted. What is necessary is some other means of conveying trust, wether that is a web of trust, or some other out of band option.
I'd gladly use a system like that. You can trivially "name" systems using their public key fingerprints, which then just means you need to *find* those sites. Right now, people find those sites three ways: they use a search engine like Google and get a link (not a problem), they follow a link from another site (not a problem), or they type in an address (problem). To handle that last one, note that the address has to come from somewhere; that source could always provide things like QR codes or other mechanisms to identify a particular address without having to enter the whole thing.
Good luck migrating from the existing system, though.
For starters mirror the current root dns but refuse to remove any domains if they were tampered with by the RIAA and the like.
Remove all squated/harvested domains. (It's easy detect those), smarter people could think of what's next but this is a pretty good start.
That wouldn't solve the problem; that would just move control from a group that *definitely* shouldn't have it to a group that would make it marginally better in a few narrow cases. I said "decentralized" because I'd like to see a system where *nobody* has that control. I don't just want to see a centralized system with a different center.
I think you missed the point; I didn't give a "definition", I gave a few examples to make the point that P2P systems and security can indeed go together. The post I replied to seemed to have the impression that P2P and security didn't mix.
Many secure peer-to-peer systems exist, generally based on cryptography; often they provide more security than centralized systems.
For instance, Tor uses secure cryptography to provide anonymity in a way that just wouldn't work in a centralized system. i2p uses cryptographic security as well.
On the one hand, I absolutely want to see control over domain names taken out of anyone's hands (not just ICANN's).
However, decentralized naming is a *hard* problem. Only one entity can control a given domain name, and something, either human or automated, must decide who gets that domain name. Whether by fiat or general consensus, some process must exist to handle the case where multiple people want the same name. ("First come first served" does not suffice unless you have fees or some other measure to prevent mass registration, and decentralized control makes those measures difficult.)
(Numbers, by comparison, prove quite trivial; just use public keys. But people don't like typing in long numbers, they like typing in *names*.)
Aside the fictional Squirtler, does Twitter have any competition?
The main competition to Twitter consists of the OStatus standard, and its primary demo site identi.ca . Unfortunately it doesn't have much non-geek traction, mostly because it doesn't have much non-geek traction; no critical mass.
And the DMCA and this insane exception-granting placation process means that unlike fair use, exceptions to the DMCA require someone to explicitly fight for them, with a default presumption of *not* allowing them.
According to the article I linked to, they access a grand total of 10 sites: microsoft.com, aol.com, ebay.com, msn.com, google.com, yahoo.com, mapquest.com, go.com, apple.com, and myspace.com.
On the one hand, I'd expect none of those sites to have a slower connection than any consumer ISP. (Some sites with large files such as video sites will throttle for bandwidth reasons, but no sane site throttles HTML and similar; better to just serve the files quickly and close the connection.)
On the other hand, that doesn't look like a particularly representative sample of "top" sites. Who uses mapquest anymore? And how often does the average user visit microsoft.com or apple.com? (As opposed to msn.com or live.com, which seem somewhat more likely for regular visits. Windows Update doesn't count, since *hopefully* that gets much more non-interactive use than interactive use. Similarly for the various Apple services, which don't necessarily live on the same server as apple.com.)
But in any case, the bandwidth of the server will matter less to SurfSpeed than the latency of responding to each request quickly so it can start the next one.
The concept of a benchmark for real-world site load times seems perfectly reasonable, but it should not have a misleading unit of "Mbps". A better idea: measure the total number of milliseconds required for page loads during some representative real-world browsing paths (*not* just site front pages either).
Despite using bandwidth units (Mbps), their "SurfSpeed" "benchmark" actually depends heavily on latency, as it tries to simulate a web browser fetching resources sequentially from a site as it discovers them.
SMP will only bring you so far - i'll bet 8 VCPU VMs on Atoms will be beat by a 2 VCPU VM on a Core 2 Duo.
Perhaps not, depending on the other load the system is working on. Because of the way VCPUs are scheduled (at least in VMWare) that 8-vCPU VM won't get a time-slice until such time as there are 8 real cores available for the duration of that slice.
Not all virtualization systems have that limitation. In a modern VM, each VCPU gets scheduled separately on the physical CPUs, rather than using gang-scheduling, for exactly the reason you described. That way, if you have a pile of N-cpu VMs, each of which just has one or two CPUs waking up periodically rather than all doing intensive computation, they can all share relatively few hardware CPUs and run efficiently.
Enterprise distributions avoid kernel version upgrades for two distinct reasons: perceived stability and fixed API/ABI for third-party modules. In this case, upgrading from 2.6.27 to 2.6.32 may well improve stability, particularly since many other distributions plan to ship 2.6.32 in their next release as well. As always, any upgrade can lead to the occasional regression that enterprise customers hate, but hey, paid support means they'll get a fix. So, that just leaves API/ABI issues, hence the discussions with ISVs and such. Third-party modules keep becoming less and less important with each new kernel version, and I can readily believe that the pain of dealing with API/ABI issues no longer outweighs the benefits of new hardware support and features provided by 2.6.32.
Because, as documented in the bugzilla entry and discussion, Entrust delegates a secondary root to CNNIC, which means CNNIC can issue certificates with a valid trust path via Entrust. The change that prompted the article submission gives CNNIC their own root CA entry.
"Furthermore,", once people have the ability to copy programs freely, it seems likely that the market for massively duplicated proprietary programs will go away in favor of a market for custom software development and support.
The FSF has said on more than one occasion that if copyright restrictions went away they'd happily rejoice, regardless of the impact of that on the GPL.
If you build a web app, it might not be able to take advantage of the phone's hardware, like the GPS. I originally built a web app but bit the bullet and wrote a native iPhone app for this very reason.
Fair point in general, but for the specific case of geolocation, some upcoming standards will allow pages to access that information if the user allows it.
That's not the way it happened. It wasn't the Mozilla contact, it was debian's own people, pointing out that their deal with mozilla was against debian principles - debian does not allow itself to accept licenses which are specific to debian, believing this could lead to it distributing non-free stuff. (After all, that agreement meant that a user couldn't take debian, call it something else, and distribute it as a new distro, because they wouldn't have that agreement for the mozilla trademarks).
While Debian indeed does not accept software which provides freedom only to Debian and not to others (point 8 of the Debian Free Software Guidelines, "License Must Not Be Specific to Debian", reflected in point 8 of the Open Source Definition), this does not in any way relate to why Debian could not distribute Firefox under the name "Firefox".
Debian has no problem with licenses that grant additional freedoms to Debian or its users, as long as everyone has all the necessary freedoms of Free Software. Debian had no problem accepting the permission to distribute Firefox as Firefox, with the understanding that Debian users who modified Firefox would have to "unbrand" it themselves.
However, Debian shipped Firefox branded as Firefox together with the unofficial logos and other branding, because Mozilla's official logos and branding did not have a Free Software license. The aforementioned contact from Mozilla, Gervase Markham, had previously given permission for Debian to do this. However, another Mozilla contact subsequently insisted that Debian could not do this, and that they must 1) ship the official (non-free) branding and 2) run every change by Mozilla reviewers before shipping it. The second condition would make Firefox maintenance an even more onerous task, and the first would make it impossible to ship Firefox in Debian main.
As a result, in order to ship Firefox at all in Debian main, Debian had to "unbrand" it.
Intel *did* introduce AES instructions. In fact, the current development version of GCC has support for them already; the release notes for GCC 4.4 say "Support for Intel AES built-in functions and code generation are available via -maes.".
If the author had instead used CC-by-nc-sa, the "community contributions" would fall under the same license, which would give him no right to sell the book with the contributions included. The copyright holder can do whatever the hell they like with their stuff. The CC (and all copyright) licenses regulates what everyone else can do with it. Which gives the author the right to sell his own work, with all of the community contributions stripped out, if he tracked them well enough to do that. It does *not* give him the right to sell all the community contributions, because the contributors individually own the copyrights on their contributions.
I presume that as the copyright holder, rather than a licensee, he's allowed to also sell copies. The question is whether the "community contributions" hold any copyright as well, and if he is only entitled to them under the CC license terms (like GPL patches without assignation of copyright). If so, he might not be within his rights to sell the book via Lulu! Unless the author established some additional terms on top of the CC-by-nc-nd license, any "community contributions" represent unauthorized derivative works.
If the author had instead used CC-by-nc-sa, the "community contributions" would fall under the same license, which would give him no right to sell the book with the contributions included.
So either way, the author has no right to sell copies of the edited book, via Lulu or otherwise.
Yay for unintended consequences. People should think twice before using a Creative Commons license that includes "nc" or "nd" terms. In addition to making the work non-free, they can lead to consequences like these.
Yes, I read the article; I wouldn't link to it otherwise. If you want more precision, s/the Consumerist's comparison/the comparison posted on the Consumerist/.
The article gives plenty of detail on their testing methodology, assuming the original poster didn't make it up, and nothing posted on the Internet can easily prove or disprove that possibility. Thus, take it with the same grain of salt you take with everything else on the Internet.
Yes, because of the obvious problems in PAYING for it. That the legislature blocked it is a good thing: universal health care does no one any good if everyone is broke. The proposed system was literally incapable of sustaining itself.
To elaborate on that: Oregon has a novel system where the government actually has to have money to spend money. Not only that, but if it doesn't use all the money it collected (and it usually doesn't), it has to give the remainder back to the taxpayers in the form of a "kicker" check.
From a website about jury duty: "It is your duty to accept what the Judge says about the laws to be applied to the case, whether you agree or disagree with the law."
I see your quote from a website, and I raise you: http://fija.org/ The quick take is that the jury gets to judge the law, as well as the defendant.
And in case FIJA doesn't convince people, how about one of the many state constitutions which explicitly spell that out:
In all criminal cases whatever, the jury shall have the right to determine the law, and the facts under the direction of the Court as to the law, and the right of new trial, as in civil cases. -- Oregon Constitution, Article I, Section 16
What god damned mook of a market researcher thought a blow by blow report of what a customer clicks on while working on a project is superior to actually talking to the customer?
A good one. Asking someone to describe their experiences with software will give you some useful high-level information, like "I want a feature that does this", or perhaps "I don't find such-and-such intuitive". However, if you want to know things like "which tools do people actually use, and how often", or "do people often look in menu X for something we put in menu Y", or "do people do a multi-step task by hand that we could make easier", or "which tools should we put on the toolbar by default and which should we stick in menus", watching real usage could provide you with data that you can't get from a survey.
(This ignores for the moment the ethical issue at hand. If you want this kind of data, do an opt-in usability study, or get people to use the software in a controlled environment.)
Slashdot Mirror
I'd gladly use a system like that. You can trivially "name" systems using their public key fingerprints, which then just means you need to *find* those sites. Right now, people find those sites three ways: they use a search engine like Google and get a link (not a problem), they follow a link from another site (not a problem), or they type in an address (problem). To handle that last one, note that the address has to come from somewhere; that source could always provide things like QR codes or other mechanisms to identify a particular address without having to enter the whole thing.
Good luck migrating from the existing system, though.
That wouldn't solve the problem; that would just move control from a group that *definitely* shouldn't have it to a group that would make it marginally better in a few narrow cases. I said "decentralized" because I'd like to see a system where *nobody* has that control. I don't just want to see a centralized system with a different center.
I think you missed the point; I didn't give a "definition", I gave a few examples to make the point that P2P systems and security can indeed go together. The post I replied to seemed to have the impression that P2P and security didn't mix.
Many secure peer-to-peer systems exist, generally based on cryptography; often they provide more security than centralized systems.
For instance, Tor uses secure cryptography to provide anonymity in a way that just wouldn't work in a centralized system. i2p uses cryptographic security as well.
On the one hand, I absolutely want to see control over domain names taken out of anyone's hands (not just ICANN's).
However, decentralized naming is a *hard* problem. Only one entity can control a given domain name, and something, either human or automated, must decide who gets that domain name. Whether by fiat or general consensus, some process must exist to handle the case where multiple people want the same name. ("First come first served" does not suffice unless you have fees or some other measure to prevent mass registration, and decentralized control makes those measures difficult.)
(Numbers, by comparison, prove quite trivial; just use public keys. But people don't like typing in long numbers, they like typing in *names*.)
The main competition to Twitter consists of the OStatus standard, and its primary demo site identi.ca . Unfortunately it doesn't have much non-geek traction, mostly because it doesn't have much non-geek traction; no critical mass.
Sounds like a good idea; they should learn to find intellectual property deeply concerning. These students already have, the hard way.
And the DMCA and this insane exception-granting placation process means that unlike fair use, exceptions to the DMCA require someone to explicitly fight for them, with a default presumption of *not* allowing them.
According to the article I linked to, they access a grand total of 10 sites: microsoft.com, aol.com, ebay.com, msn.com, google.com, yahoo.com, mapquest.com, go.com, apple.com, and myspace.com.
On the one hand, I'd expect none of those sites to have a slower connection than any consumer ISP. (Some sites with large files such as video sites will throttle for bandwidth reasons, but no sane site throttles HTML and similar; better to just serve the files quickly and close the connection.)
On the other hand, that doesn't look like a particularly representative sample of "top" sites. Who uses mapquest anymore? And how often does the average user visit microsoft.com or apple.com? (As opposed to msn.com or live.com, which seem somewhat more likely for regular visits. Windows Update doesn't count, since *hopefully* that gets much more non-interactive use than interactive use. Similarly for the various Apple services, which don't necessarily live on the same server as apple.com.)
But in any case, the bandwidth of the server will matter less to SurfSpeed than the latency of responding to each request quickly so it can start the next one.
The concept of a benchmark for real-world site load times seems perfectly reasonable, but it should not have a misleading unit of "Mbps". A better idea: measure the total number of milliseconds required for page loads during some representative real-world browsing paths (*not* just site front pages either).
Despite using bandwidth units (Mbps), their "SurfSpeed" "benchmark" actually depends heavily on latency, as it tries to simulate a web browser fetching resources sequentially from a site as it discovers them.
Found this report analyzing the article and the benchmark: http://blog.ookla.com/2010/06/23/the-fastest-isps-not-quite/
SMP will only bring you so far - i'll bet 8 VCPU VMs on Atoms will be beat by a 2 VCPU VM on a Core 2 Duo.
Perhaps not, depending on the other load the system is working on. Because of the way VCPUs are scheduled (at least in VMWare) that 8-vCPU VM won't get a time-slice until such time as there are 8 real cores available for the duration of that slice.
Not all virtualization systems have that limitation. In a modern VM, each VCPU gets scheduled separately on the physical CPUs, rather than using gang-scheduling, for exactly the reason you described. That way, if you have a pile of N-cpu VMs, each of which just has one or two CPUs waking up periodically rather than all doing intensive computation, they can all share relatively few hardware CPUs and run efficiently.
Enterprise distributions avoid kernel version upgrades for two distinct reasons: perceived stability and fixed API/ABI for third-party modules. In this case, upgrading from 2.6.27 to 2.6.32 may well improve stability, particularly since many other distributions plan to ship 2.6.32 in their next release as well. As always, any upgrade can lead to the occasional regression that enterprise customers hate, but hey, paid support means they'll get a fix. So, that just leaves API/ABI issues, hence the discussions with ISVs and such. Third-party modules keep becoming less and less important with each new kernel version, and I can readily believe that the pain of dealing with API/ABI issues no longer outweighs the benefits of new hardware support and features provided by 2.6.32.
Because, as documented in the bugzilla entry and discussion, Entrust delegates a secondary root to CNNIC, which means CNNIC can issue certificates with a valid trust path via Entrust. The change that prompted the article submission gives CNNIC their own root CA entry.
"Furthermore,", once people have the ability to copy programs freely, it seems likely that the market for massively duplicated proprietary programs will go away in favor of a market for custom software development and support.
The FSF has said on more than one occasion that if copyright restrictions went away they'd happily rejoice, regardless of the impact of that on the GPL.
Furthermore,
If you build a web app, it might not be able to take advantage of the phone's hardware, like the GPS. I originally built a web app but bit the bullet and wrote a native iPhone app for this very reason.
Fair point in general, but for the specific case of geolocation, some upcoming standards will allow pages to access that information if the user allows it.
https://developer.mozilla.org/En/Using_geolocation
That's not the way it happened. It wasn't the Mozilla contact, it was debian's own people, pointing out that their deal with mozilla was against debian principles - debian does not allow itself to accept licenses which are specific to debian, believing this could lead to it distributing non-free stuff. (After all, that agreement meant that a user couldn't take debian, call it something else, and distribute it as a new distro, because they wouldn't have that agreement for the mozilla trademarks).
While Debian indeed does not accept software which provides freedom only to Debian and not to others (point 8 of the Debian Free Software Guidelines, "License Must Not Be Specific to Debian", reflected in point 8 of the Open Source Definition), this does not in any way relate to why Debian could not distribute Firefox under the name "Firefox".
Debian has no problem with licenses that grant additional freedoms to Debian or its users, as long as everyone has all the necessary freedoms of Free Software. Debian had no problem accepting the permission to distribute Firefox as Firefox, with the understanding that Debian users who modified Firefox would have to "unbrand" it themselves.
However, Debian shipped Firefox branded as Firefox together with the unofficial logos and other branding, because Mozilla's official logos and branding did not have a Free Software license. The aforementioned contact from Mozilla, Gervase Markham, had previously given permission for Debian to do this. However, another Mozilla contact subsequently insisted that Debian could not do this, and that they must 1) ship the official (non-free) branding and 2) run every change by Mozilla reviewers before shipping it. The second condition would make Firefox maintenance an even more onerous task, and the first would make it impossible to ship Firefox in Debian main.
As a result, in order to ship Firefox at all in Debian main, Debian had to "unbrand" it.
Intel *did* introduce AES instructions. In fact, the current development version of GCC has support for them already; the release notes for GCC 4.4 say "Support for Intel AES built-in functions and code generation are available via -maes.".
If the author had instead used CC-by-nc-sa, the "community contributions" would fall under the same license, which would give him no right to sell the book with the contributions included.
So either way, the author has no right to sell copies of the edited book, via Lulu or otherwise.
Yay for unintended consequences. People should think twice before using a Creative Commons license that includes "nc" or "nd" terms. In addition to making the work non-free, they can lead to consequences like these.
Yes, I read the article; I wouldn't link to it otherwise. If you want more precision, s/the Consumerist's comparison/the comparison posted on the Consumerist/.
The article gives plenty of detail on their testing methodology, assuming the original poster didn't make it up, and nothing posted on the Internet can easily prove or disprove that possibility. Thus, take it with the same grain of salt you take with everything else on the Internet.
For more proof that Monster has nothing special, see the Consumerist's comparison of Monster Cable versus wire coat hangers. Nobody could tell the difference.
To elaborate on that: Oregon has a novel system where the government actually has to have money to spend money. Not only that, but if it doesn't use all the money it collected (and it usually doesn't), it has to give the remainder back to the taxpayers in the form of a "kicker" check.
And in case FIJA doesn't convince people, how about one of the many state constitutions which explicitly spell that out:
In all criminal cases whatever, the jury shall have the right to determine the
law, and the facts under the direction of the Court as to the law, and the
right of new trial, as in civil cases.
-- Oregon Constitution, Article I, Section 16
A good one. Asking someone to describe their experiences with software will give you some useful high-level information, like "I want a feature that does this", or perhaps "I don't find such-and-such intuitive". However, if you want to know things like "which tools do people actually use, and how often", or "do people often look in menu X for something we put in menu Y", or "do people do a multi-step task by hand that we could make easier", or "which tools should we put on the toolbar by default and which should we stick in menus", watching real usage could provide you with data that you can't get from a survey.
(This ignores for the moment the ethical issue at hand. If you want this kind of data, do an opt-in usability study, or get people to use the software in a controlled environment.)