Nice try at a troll, but the entire problem is that FaunOS doesn't include apt-get. I am not aware of any apt-gettable distributions that even install onto a modest sized USB key, let alone one that deals well with being moved from machine to machine on a daily basis.
In addition, merely including apt-get is not the whole story. There needs to be a community in place to report and respond to security issues. There needs to be a commitment towards maintaining older versions, because not everyone enjoys upgrading their OS every year. These requirements alone (and there is nothing ignorant, FUD, or old school about them) rule out everything except Redhat, SuSE, Ubuntu, and possibly Debian. Out of these four, none of them is designed for USB keys, and none of them works anywhere near as well as FaunOS in that setting.
All moving violations are part of the criminal code of your state; they're laws passed to restrict certain driving behaviors in the interest of highway safety.
Funny, the last time I got a speeding ticket, it said (emphasis added):
This is a non-criminal offense that cannot be punished by a jail sentence.
So, I don't see how traffic violations would be considered part of criminal code or criminal court (although you're right about not going to jail).
making the boot device detachable and largely hardware agnostic is an attractive solution. The idea is that users carry and maintain only a single copy of an operating environment which they can run on pretty much any device of their choosing. That way, the user accumulates and maintains know-how on a single evolving operating environment rather than having to duplicate that effort across multiple machines. Does this makes sense?
It makes sense, but the implementation leaves something to be desired. In this day and age, an operating system or operating environment is not viable for everyday use unless it has timely and usable mechanisms for installing, reporting, and keeping track of security updates. The problem is that very few linux distributions provide this kind of infrastructure, and of the ones that do, none of them is small enough to fit on a boot device.
What I want to see is something like FaunOS where security updates are reported and published in a transparent and timely fashion, and where a large block of updates can be applied without filling up the disk or reinstalling the system entirely. Ideally, the maintainers would also commit to supporting old versions for seven years (like Redhat), or even three years (like Ubuntu). If this sound impossible, it probably is -- maintaining a linux distribution is a lot of work, and only the large organizations have the resources to do it.
To add to the chorus of replies, Habeas corpus for non-citizens is crucial in a way that welfare and voting rights are not.
Think about it for a moment. If habeas corpus is reserved for citizens, then what happens when a US citizen is arrested and falsely accused of being a non-citizen. How can said US citizen prove that he is a citizen, without habeas corpus?
Re:Does XEN have a future?
on
Running Xen
·
· Score: 2, Informative
There are a few things that Xen supports that KVM doesn't, such as live migration.
Wait, what? KVM supports live migration, and in fact KVM supports it better than Xen ever did.
Xen allows live migration only between machines with identical or very similar processors. KVM supports live migration between any two systems that can run KVM. For example, if you want to live migrate from an Intel to an AMD host, KVM is your only option. If you want to live migrate a 32-bit guest between a 32-bit host and a 64-bit host, KVM will do that, Xen won't.
Re:Does XEN have a future?
on
Running Xen
·
· Score: 2, Insightful
First of all, I'm not fighting a war here. I'm just saying nature will take its course, and there is nothing you or I can do to stop it.
KVM will scale up to the server space. There is no technical reason why KVM requires "running everything as VMs on a desktop", even though that happens to be required today. In fact I guarantee you that one day KVM will be viable in the server arena. Once that happens, Xen is dead.
By contrast, Xen can never scale down to laptop or even desktop users, because the hypervisor design imposes unacceptable usage constraints for such users.
I said before, and I'll say again, it is very hard for any server-only computing technology to compete against mainstream alternatives. Admittedly, it is easier in the case of software (e.g. Oracle) than hardware (e.g. x86). However, x86 virtualization happens to be moving in the direction of hardware. All of these factors weigh against the hypervisor design. Incidentally, all of Xen's competitors, including VMware and Microsoft, offer at least some virtualization products not based on hypervisors. Xen is the only company tethered to hypervisors, and that does not bode well for them.
You say yourself that "people will try to force fit one solution to the other's area" but then you dismiss this as a non-issue. I think it is a bigger issue than you realize. For example, the reviewer of this book, among all people, complains several times in this review that the book is overkill for what he needs. It looks like he would be better served by KVM. If there is a "war" to be fought, then the goal must be to educate readers about the pros and cons of each option, so that they can choose intelligently. That's all I'm trying to do.
Re:Does XEN have a future?
on
Running Xen
·
· Score: 3, Insightful
Xen has pretty much no support for laptops. Unfortunately for Xen, it's becoming pretty clear that laptops are the future as far as general purpose computing goes. So I would say that Xen has no future.
The problem (and it is a showstopper) is that Xen has no ability to perform power management. Even worse, the design of Xen makes it almost impossible to support power management in any sane way. In Xen, every OS on your system runs in a virtual machine. Even the so-called "host" OS, which has special privileges for hardware access, runs in a virtual machine. The actual host kernel is a bare-bones hypervisor with so few features that it cannot be called a full-blown OS.
Power management is very difficult to do under the Xen architecture, because ACPI power management requires all of the power management code to run in the OS. Now, an OS running inside a VM has no ability to monitor power usage for other VMs -- that's the whole point of a VM, after all. So, under the Xen design, the power management code cannot run in the "host" OS. It has to run in the hypervisor.
However, power management is complicated enough, and involves enough dependencies, that by the time your hypervisor has implemented power management, it is already bloated and featureful enough to constitute a full-blown OS. Therein lies the problem: a full-blown OS is very difficult to develop in this day and age, and in order to succeed you need a large team. If you screw up, then the resulting product is fragile and unstable, and nobody wants that. Xen is a very small team compared to Microsoft, or Linux, or even FreeBSD. They have no chance to develop an OS on their own.
One might be tempted to implement some sort of passthrough design where the hypervisor piggybacks off of the power management code in the "host" OS, but such a design requires forking the "host" OS and still involves almost as much hypervisor bloat as implementing power management itself.
In short, KVM is the future, at least for regular users like you and me. KVM has no problems with power management, because under KVM the actual host kernel is the exact same Linux kernel that you normally use, with a complete ACPI implementation. Xen might have a place when it comes to big iron and server rooms, but history shows that very few technologies can survive in server-only space when there is mass-market competition (Itanium anyone?).
In fact, with the soaring cost of energy these days, power consumption is becoming a huge issue even on servers, so it's fair to say that Xen's days are numbered even in the server space unless they drastically change their design.
Look, I'm sure Mark Shuttleworth is a great businessman and all, but this analogy falls short of the mark.
Car dealerships and hot dog stands are physical retail outlets. A physical retail outlet benefits greatly from being located wherever the customers are. Therefore, some locations (the ones with more customers) are more desirable than others, and businesses will tend to cluster in those locations.
Since not all types of stores benefit from location to the same degree, the ones that benefit more (such as fast food outlets) are also willing to pay more for the best locations, which is why they get them.
It is important to note that no coordination between companies is required for retail clustering -- all you need is to have multiple companies competing for the same locations.
I see no reason why clustering would apply to release dates. Sure, if something is seasonally dependent (e.g. Christmas cards) then companies will cluster their product releases temporally, exactly as Shuttleworth predicts, but it doesn't involve any coordination between companies. However, the Linux market doesn't strike me as especially seasonal in nature, so I have a hard time seeing how clustering applies. Temporal clustering of Linux releases may well still be a good idea, but if so it won't be based on the same rationale as retail store clustering.
The great thing about the rpm package management system on Fedora and Red Hat is, that the source rpms always include the pristine, original sourcecode as provided by upstream. Yeah, source debs have that too.
The problem with source debs is that they aggregate all the patches into a single diff, so you can't easily tell what each individual modification is for. Source rpms on the other hand can (and almost always do) contain multiple patch files, where each individual patch file involves one single conceptual change to the codebase.
When the patches are separated out into individual diffs, it's much easier to examine them one by one for correctness. I suspect (although we will never really know) that the "one big diff" limitation played a role in allowing this error to slip through the cracks.
The correct solution to this problem is to lower the price of housing
When you're finished with the magic wand, can I borrow it? See, I've invented a perpetual motion machine and it works fine except I have to wind it up every day.
There's nothing magic about it. If the American government would stop
providing special subsidies to homeowners, then the real estate market
will correct itself automatically. Now, I'm not saying the free market
is a panacea, but it's a hell of a lot better than central planning.
Repealing the mortgage interest tax deduction or abolishing Fannie Mae
is not magic, considering that every country in the world except the US
is capable of doing it. The real reason it will never happen is not
lack of a magic wand, but because people like you pour scorn on anything
even remotely resembling the idea of giving equal treatment to housing.
Most of the towns around NYC where the soccer mom lifestyle exists also are priced that $200k a year salary is the entry level. The median housing prices are around $600K and property taxes are high. So anyone who makes less than the requisite $200K lives farther away, and your don't have to get all that far away for a rush hour commute to take two hours or more.
The correct solution to this problem is to lower the price of housing, but unfortunately the American electorate so far seems determined to make the problem even worse by continuing to artificially prop up the price of housing for as long as humanly possible.
Yes, the entities that are supposed to protect your identity from fraudulent use should be held accountable if it is indeed their fault, but you can still become a victim of fraud from your own faults, such as falling for a phishing website. Blaming your bank because you failed to check that the URL is authentic is just as irresponsible as losing sensitive information and not bothering to inform your clients out of fear of a lost reputation.
I make a distinction between scammers that steal your "identity" and scammers that steal truly sensitive information like online banking passwords. If you give your password to a phishing website then any problems that arise are clearly your fault and the bank shares only minor responsibility for the incident. Even in this case, the bank is not completely innocent, because there are steps the bank can take to defend against password theft (e.g. one-time passwords, two-factor authentication).
However, in many cases, so-called identity theft involves only public information such as social security number, mothers maiden name, and so on. Even something like a credit card number or bank account number has to be considered public information, since anyone who swipes your card or receives a check from you has this information. These cases are clearly the fault of the bank or whatever entity it is that knowingly conducts authorization activities based on only public credentials.
The main point, however, is that neither of these two scenarios is well described by the term "identity theft." In the first case, something like "password theft" would be more appropriate, and the second case is clearly fraud of some sort, as nothing is being stolen directly from the victim.
This is a case of fraud, not theft. This man's identity was not "stolen," but used fraudulently in an attempt to gain illegitimate access to goods and services under the guise of someone else. Using words like "identity theft" is no better than the RIAA calling copyright infringement "theft."
You make a good point. I would go further and say that the phrase "identity theft" is deliberately promoted by corporations and governments as a way of avoiding responsibility for the problem. Unfortunately, all indications are that it has worked spectacularly so far.
The phrase "identity theft" implies that you are responsible for keeping your identity away from the evil thieves. Never mind that an identity cannot be kept secret, that it cannot be replaced, and that there is basically no way to prevent someone from "stealing" your identity. Any solution to "identity theft" that involves theft prevention is guaranteed to fail, because one's identity by definition cannot be concealed.
The phrase "identity fraud" emphasizes the real nature of the crime: it is a fraud. This fraud involves the perpetrator and the company or entity that deals with the perpetrator. It does not involve you, so there is no way you can prevent it from happening. An honest attempt at solving the problem of identity fraud would start with the companies that cause the problem in the first place. However, since this is exactly what big business does not want, they prefer to use the deceptive term "identity theft" instead. By misleading the public in this way, the powers that be insure that a true solution to the problem (one that starts with them) will never be achieved.
Everyone knows that biometric data can be stolen, just like every other means of identifying yourself.
Part of the problem is that you (and many other people) seem to think authentication is the same as identification. It's not. Biometrics are awesome as part of two-factor authentication, but they're horrible as a means of identifying yourself.
Identification is the problem of determining, on your own, the identity of a given person.
Authentication is the problem of determining whether or not a given identity corresponds to a given person.
The difference is that, in authentication, you are given both a single person and a single identity, and your job is to answer true or false as to whether they match. Authentication is a yes/no question: your answer is either yes or no. In identification, you are given only a person, and your job is to produce a matching identity. Identification is not usually a yes/no question, although in some cases it can be disguised as one -- for example: to answer "Is this person a terrorist?" you typically have to determine a person's true identity (which a terrorist is not likely to offer to you) and then check that identity against known terrorist databases.
National governments are fully aware of this distinction, and they exploit public confusion to further their agenda. Biometrics are being advertised as authentication tools (does this passport accurately identify this person?), for which they work pretty well, but in reality governments are using biometrics for identification (is this person a terrorist?), an approach which has fail written all over it.
Even for authorization, biometrics are not a panacea, but they are at least a useful tool capable of contributing some benefits when employed properly. For identification, biometrics are an unmitigated disaster, for many reasons, chief among them the base rate fallacy, which says that the accuracy of an identity test drops precipitiously when the test is presented with large databases of identities.
3. What is the false positive rate of such monitoring? Here, we have a cute example of a sick cat setting off a false positive. What about other incidents like this that fail to get into the newspaper? I'm not sure this matters. Are people's rights being trampled as a result of this monitoring? I'd feel more strongly about this story if there was mention of someone getting arrested, hassled, held, etc. On the other hand, if they detect cancer patients, they must pull people over pretty frequently, and the program may never catch a terrorist... well, good thing I'm not in politics.
The false positive rate does matter, regardless of whether or not rights are being trampled. When you conduct any sort of large scale surveillance activity, the base rate fallacy implies that most of the triggering events will be false positives. With too many false positives, your surveillance program is worse than useless -- it wastes money that could otherwise be better used on other security initiatives.
I know there is some emotional appeal in arguing that "if it saves even one life, etc. etc. then it's worth any amount of money" but in the real world that's just not true. In the real world, spending one billion dollars to save a life might be a bad idea if spending that same money on some other program would save two lives. In comparing the relative merits of two or more different security proposals, the false positive rate is one important factor to consider, because it affects the cost/benefit analysis.
Of course, people's rights matter as well, because that also affects the cost/benefit analysis. Unfortunately, the American public is seemingly too dumb to perform any sort of analysis involving more than one variable. Since the false positive rate involves math, it doesn't have any political appeal at all. Hence the Republicans fixate only on the terrorists, and the Democrats when not fixating on the terrorists focus only on civil liberties to the exclusion of all else.
If you have enough energy to check slashdot regularly, you have enough energy to check a wikipedia article once a week to see that information you obviously care about is maintained.
I'm sorry, but this approach does not scale. Slashdot has one single front page to check, and if you miss a week then no one cares. Wikipedia has hundreds if not thousands of cosmology articles alone, and each week that you miss is an extra week of work later on to undo the damage. Even if you somehow become enough of an expert in mediawiki to use watchlists etc. to your advantage, there comes a point somewhere between "hundreds" and "thousands" of pages when you cannot keep up with the changes.
Moreover, keeping up with the changes is the easy part. The hard part is trying to maintain your article in the face of the changes, against hordes of unwashed barbarians that outnumber you and other experts by at least a thousand to one. I'm an academic, not a politician. I might be able to maintain one or two pages, but if you multiply this effort by several hundred pages, then you can easily see why real experts are driven away from Wikipedia. If I spent half the time needed to maintain Wikipedia articles, I wouldn't be able to maintain my expertise in the original subject to begin with.
No one is going to make a full time job of just babysitting one or two articles in perpetuity. Any solution that you propose has to scale to many hundreds if not thousands of articles, or it will just be ignored.
Shows exactly what's wrong with it too... he began to rely on the chemical to do all of his thinking for him, as the results show plainly.
It's actually hard to find anything wrong with the results. Erdos is one of the greatest mathematicians of all time. I work in applied mathematics (cryptography) and some of my work relies on his discoveries. I'm not going to exaggerate and say he invented the internet, but there is foundational material in computer science that derives from his findings. I'm personally glad that Erdos took amphetamines, regardless of whether he depended on it. His drug use harmed at most one man, compared to the six billion others in the world who benefited from his work.
Also, you'd be hard pressed to argue that amphetamine use was harmful to Erdos. He lived a long life.
Getting the key involves solving a discrete log problem for one instance of an elliptic curve. Discrete log problem is an unsolved mathematical problem.
You misunderstand the nature of the backdoor. Yes, discrete logarithm is very hard, but the inverse problem (exponentiation) is very easy. The NSA could have very easily produced the point via exponentiation, in which case they know the backdoor. For anyone else other than the NSA, accessing the backdoor requires computing a discrete logarithm.
It's a bit like factoring integers vs. multiplying integers. Factoring is very hard, but you can easily backdoor a factoring-based scheme without factoring anything just by picking the primes in secret, and presenting the product as if it were the original integer.
It hardly seems worth mentioning, but DRM is costly even if you avoid all media. If nothing else, DRM increases the cost of hardware).
Sure, you can boycott DRM hardware, to a point, but at some point you have no choice. For example, DVI monitors are limited in resolution, and if you want to upgrade to HDMI, all HDMI monitors come with DRM. Also, what choice do you have, if all hardware by law must support DRM?
I saw this point raised on LWN recently, and it seems relevant to bring it up here. Any observer who connects the dots will realize that Mozilla is killing off their Thunderbird email client, intentionally, and is doing so at the behest of Google.
Let's look at the facts. Mozilla is a highly profitable organization. You would think that Mozilla could afford to spend at least a little money on hiring Thunderbird developers. Yet in reality Mozilla has done the opposite: they have completely abandoned Thunderbird.
Why? Because of money.
The vast majority of Mozilla's income comes from Google. One of Google's main products is Gmail. Thunderbird competes with Gmail. So it makes sense that Google wants Thunderbird dead. Of course, they're not going to announce their intentions in a press release, but in reality that's exactly what's going on. Announcements like this one only make their plan more obvious than before.
This kind of anti-competitive behavior is exactly why most Slashdot readers hate Microsoft. Why is Google getting a free pass here?
it could indicate that they fudged their data set (quite possibly unconsciously) to get that answer. I already mentioned why the data set in the study is of high quality.
I'd like to see some other studies on independently derived data before I'd buy into the equation for decay rate having been unequivocally established.
You won't be able to gather any more data for English, because English only has a few hundred irregular verbs to begin with, and the study already accounted for all of them. It would indeed be interesting to compare English with other languages, but there the problem is that few languages have as many irregular verbs as English, and most of the ones that do (i.e. Latin, Italian) have more than one family of regular verbs, making direct comparison difficult.
The only novelty of this research is the computational ability to carry out an accurate simulation.
I'm a mathematician, not a linguist, and to me the article is quite newsworthy, even though the mathematics used in the study (that is, statistics) lies outside my research area. It's possible that the majority of linguists (such as you) may not be able to appreciate the novelty of this discovery, because they lack the mathematical background to evaluate the relative strength of this particular statistical characterization compared with other ones that have appeared in analogous studies.
The computation carried out in the article is not merely a matter of "ability", nor is it fair to characterize it as a simulation. If you read the original article, you'll find that they derive the square-root law for verb decay using two intrinsically different approaches (three if you count the zipfian extrapolation). The most dramatic difference is that the first approach does not on the historical dates of Old and Middle English, whereas the second one does. There is no mathematics-based reason in general why these two approaches would even yield a square-root law at all. The fact that they both produce the same square root law, with coefficient values within three percent of each other, is actually (from a mathematics perspective) quite shocking. It indicates very strongly that their quantification of decay rates is right and likely to hold for future centures (much more strongly than if they had merely presented one statistical fit, which is the norm in most articles).
A crucial observation is that the data set that they use is not self-selected or biased in any way -- it is simply a complete list of all the irregular verbs in the English language for which documentation of the Old English forms could be found. In my experience it is quite rare for a naturally occurring data set such as this one to conform to two distinct statistical models in exactly the same way.
Slashdot Mirror
In addition, merely including apt-get is not the whole story. There needs to be a community in place to report and respond to security issues. There needs to be a commitment towards maintaining older versions, because not everyone enjoys upgrading their OS every year. These requirements alone (and there is nothing ignorant, FUD, or old school about them) rule out everything except Redhat, SuSE, Ubuntu, and possibly Debian. Out of these four, none of them is designed for USB keys, and none of them works anywhere near as well as FaunOS in that setting.
Funny, the last time I got a speeding ticket, it said (emphasis added):
So, I don't see how traffic violations would be considered part of criminal code or criminal court (although you're right about not going to jail).It makes sense, but the implementation leaves something to be desired. In this day and age, an operating system or operating environment is not viable for everyday use unless it has timely and usable mechanisms for installing, reporting, and keeping track of security updates. The problem is that very few linux distributions provide this kind of infrastructure, and of the ones that do, none of them is small enough to fit on a boot device.
What I want to see is something like FaunOS where security updates are reported and published in a transparent and timely fashion, and where a large block of updates can be applied without filling up the disk or reinstalling the system entirely. Ideally, the maintainers would also commit to supporting old versions for seven years (like Redhat), or even three years (like Ubuntu). If this sound impossible, it probably is -- maintaining a linux distribution is a lot of work, and only the large organizations have the resources to do it.
To add to the chorus of replies, Habeas corpus for non-citizens is crucial in a way that welfare and voting rights are not.
Think about it for a moment. If habeas corpus is reserved for citizens, then what happens when a US citizen is arrested and falsely accused of being a non-citizen. How can said US citizen prove that he is a citizen, without habeas corpus?
Wait, what? KVM supports live migration, and in fact KVM supports it better than Xen ever did.
Xen allows live migration only between machines with identical or very similar processors. KVM supports live migration between any two systems that can run KVM. For example, if you want to live migrate from an Intel to an AMD host, KVM is your only option. If you want to live migrate a 32-bit guest between a 32-bit host and a 64-bit host, KVM will do that, Xen won't.
KVM will scale up to the server space. There is no technical reason why KVM requires "running everything as VMs on a desktop", even though that happens to be required today. In fact I guarantee you that one day KVM will be viable in the server arena. Once that happens, Xen is dead.
By contrast, Xen can never scale down to laptop or even desktop users, because the hypervisor design imposes unacceptable usage constraints for such users.
I said before, and I'll say again, it is very hard for any server-only computing technology to compete against mainstream alternatives. Admittedly, it is easier in the case of software (e.g. Oracle) than hardware (e.g. x86). However, x86 virtualization happens to be moving in the direction of hardware. All of these factors weigh against the hypervisor design. Incidentally, all of Xen's competitors, including VMware and Microsoft, offer at least some virtualization products not based on hypervisors. Xen is the only company tethered to hypervisors, and that does not bode well for them.
You say yourself that "people will try to force fit one solution to the other's area" but then you dismiss this as a non-issue. I think it is a bigger issue than you realize. For example, the reviewer of this book, among all people, complains several times in this review that the book is overkill for what he needs. It looks like he would be better served by KVM. If there is a "war" to be fought, then the goal must be to educate readers about the pros and cons of each option, so that they can choose intelligently. That's all I'm trying to do.
The problem (and it is a showstopper) is that Xen has no ability to perform power management. Even worse, the design of Xen makes it almost impossible to support power management in any sane way. In Xen, every OS on your system runs in a virtual machine. Even the so-called "host" OS, which has special privileges for hardware access, runs in a virtual machine. The actual host kernel is a bare-bones hypervisor with so few features that it cannot be called a full-blown OS.
Power management is very difficult to do under the Xen architecture, because ACPI power management requires all of the power management code to run in the OS. Now, an OS running inside a VM has no ability to monitor power usage for other VMs -- that's the whole point of a VM, after all. So, under the Xen design, the power management code cannot run in the "host" OS. It has to run in the hypervisor.
However, power management is complicated enough, and involves enough dependencies, that by the time your hypervisor has implemented power management, it is already bloated and featureful enough to constitute a full-blown OS. Therein lies the problem: a full-blown OS is very difficult to develop in this day and age, and in order to succeed you need a large team. If you screw up, then the resulting product is fragile and unstable, and nobody wants that. Xen is a very small team compared to Microsoft, or Linux, or even FreeBSD. They have no chance to develop an OS on their own.
One might be tempted to implement some sort of passthrough design where the hypervisor piggybacks off of the power management code in the "host" OS, but such a design requires forking the "host" OS and still involves almost as much hypervisor bloat as implementing power management itself.
In short, KVM is the future, at least for regular users like you and me. KVM has no problems with power management, because under KVM the actual host kernel is the exact same Linux kernel that you normally use, with a complete ACPI implementation. Xen might have a place when it comes to big iron and server rooms, but history shows that very few technologies can survive in server-only space when there is mass-market competition (Itanium anyone?).
In fact, with the soaring cost of energy these days, power consumption is becoming a huge issue even on servers, so it's fair to say that Xen's days are numbered even in the server space unless they drastically change their design.
Car dealerships and hot dog stands are physical retail outlets. A physical retail outlet benefits greatly from being located wherever the customers are. Therefore, some locations (the ones with more customers) are more desirable than others, and businesses will tend to cluster in those locations.
Since not all types of stores benefit from location to the same degree, the ones that benefit more (such as fast food outlets) are also willing to pay more for the best locations, which is why they get them.
It is important to note that no coordination between companies is required for retail clustering -- all you need is to have multiple companies competing for the same locations.
I see no reason why clustering would apply to release dates. Sure, if something is seasonally dependent (e.g. Christmas cards) then companies will cluster their product releases temporally, exactly as Shuttleworth predicts, but it doesn't involve any coordination between companies. However, the Linux market doesn't strike me as especially seasonal in nature, so I have a hard time seeing how clustering applies. Temporal clustering of Linux releases may well still be a good idea, but if so it won't be based on the same rationale as retail store clustering.
The problem with source debs is that they aggregate all the patches into a single diff, so you can't easily tell what each individual modification is for. Source rpms on the other hand can (and almost always do) contain multiple patch files, where each individual patch file involves one single conceptual change to the codebase.
When the patches are separated out into individual diffs, it's much easier to examine them one by one for correctness. I suspect (although we will never really know) that the "one big diff" limitation played a role in allowing this error to slip through the cracks.
There is also an awesome graphic novel from Technology Review, containing an entertaining yet factual account of the history of the Phoenix mission.
There's nothing magic about it. If the American government would stop providing special subsidies to homeowners, then the real estate market will correct itself automatically. Now, I'm not saying the free market is a panacea, but it's a hell of a lot better than central planning.
Repealing the mortgage interest tax deduction or abolishing Fannie Mae is not magic, considering that every country in the world except the US is capable of doing it. The real reason it will never happen is not lack of a magic wand, but because people like you pour scorn on anything even remotely resembling the idea of giving equal treatment to housing.
The correct solution to this problem is to lower the price of housing, but unfortunately the American electorate so far seems determined to make the problem even worse by continuing to artificially prop up the price of housing for as long as humanly possible.
I make a distinction between scammers that steal your "identity" and scammers that steal truly sensitive information like online banking passwords. If you give your password to a phishing website then any problems that arise are clearly your fault and the bank shares only minor responsibility for the incident. Even in this case, the bank is not completely innocent, because there are steps the bank can take to defend against password theft (e.g. one-time passwords, two-factor authentication).
However, in many cases, so-called identity theft involves only public information such as social security number, mothers maiden name, and so on. Even something like a credit card number or bank account number has to be considered public information, since anyone who swipes your card or receives a check from you has this information. These cases are clearly the fault of the bank or whatever entity it is that knowingly conducts authorization activities based on only public credentials.
The main point, however, is that neither of these two scenarios is well described by the term "identity theft." In the first case, something like "password theft" would be more appropriate, and the second case is clearly fraud of some sort, as nothing is being stolen directly from the victim.
You make a good point. I would go further and say that the phrase "identity theft" is deliberately promoted by corporations and governments as a way of avoiding responsibility for the problem. Unfortunately, all indications are that it has worked spectacularly so far.
The phrase "identity theft" implies that you are responsible for keeping your identity away from the evil thieves. Never mind that an identity cannot be kept secret, that it cannot be replaced, and that there is basically no way to prevent someone from "stealing" your identity. Any solution to "identity theft" that involves theft prevention is guaranteed to fail, because one's identity by definition cannot be concealed.
The phrase "identity fraud" emphasizes the real nature of the crime: it is a fraud. This fraud involves the perpetrator and the company or entity that deals with the perpetrator. It does not involve you, so there is no way you can prevent it from happening. An honest attempt at solving the problem of identity fraud would start with the companies that cause the problem in the first place. However, since this is exactly what big business does not want, they prefer to use the deceptive term "identity theft" instead. By misleading the public in this way, the powers that be insure that a true solution to the problem (one that starts with them) will never be achieved.
Part of the problem is that you (and many other people) seem to think authentication is the same as identification. It's not. Biometrics are awesome as part of two-factor authentication, but they're horrible as a means of identifying yourself.
Identification is the problem of determining, on your own, the identity of a given person.
Authentication is the problem of determining whether or not a given identity corresponds to a given person.
The difference is that, in authentication, you are given both a single person and a single identity, and your job is to answer true or false as to whether they match. Authentication is a yes/no question: your answer is either yes or no. In identification, you are given only a person, and your job is to produce a matching identity. Identification is not usually a yes/no question, although in some cases it can be disguised as one -- for example: to answer "Is this person a terrorist?" you typically have to determine a person's true identity (which a terrorist is not likely to offer to you) and then check that identity against known terrorist databases.
National governments are fully aware of this distinction, and they exploit public confusion to further their agenda. Biometrics are being advertised as authentication tools (does this passport accurately identify this person?), for which they work pretty well, but in reality governments are using biometrics for identification (is this person a terrorist?), an approach which has fail written all over it.
Even for authorization, biometrics are not a panacea, but they are at least a useful tool capable of contributing some benefits when employed properly. For identification, biometrics are an unmitigated disaster, for many reasons, chief among them the base rate fallacy, which says that the accuracy of an identity test drops precipitiously when the test is presented with large databases of identities.
The false positive rate does matter, regardless of whether or not rights are being trampled. When you conduct any sort of large scale surveillance activity, the base rate fallacy implies that most of the triggering events will be false positives. With too many false positives, your surveillance program is worse than useless -- it wastes money that could otherwise be better used on other security initiatives.
I know there is some emotional appeal in arguing that "if it saves even one life, etc. etc. then it's worth any amount of money" but in the real world that's just not true. In the real world, spending one billion dollars to save a life might be a bad idea if spending that same money on some other program would save two lives. In comparing the relative merits of two or more different security proposals, the false positive rate is one important factor to consider, because it affects the cost/benefit analysis.
Of course, people's rights matter as well, because that also affects the cost/benefit analysis. Unfortunately, the American public is seemingly too dumb to perform any sort of analysis involving more than one variable. Since the false positive rate involves math, it doesn't have any political appeal at all. Hence the Republicans fixate only on the terrorists, and the Democrats when not fixating on the terrorists focus only on civil liberties to the exclusion of all else.
I'm sorry, but this approach does not scale. Slashdot has one single front page to check, and if you miss a week then no one cares. Wikipedia has hundreds if not thousands of cosmology articles alone, and each week that you miss is an extra week of work later on to undo the damage. Even if you somehow become enough of an expert in mediawiki to use watchlists etc. to your advantage, there comes a point somewhere between "hundreds" and "thousands" of pages when you cannot keep up with the changes.
Moreover, keeping up with the changes is the easy part. The hard part is trying to maintain your article in the face of the changes, against hordes of unwashed barbarians that outnumber you and other experts by at least a thousand to one. I'm an academic, not a politician. I might be able to maintain one or two pages, but if you multiply this effort by several hundred pages, then you can easily see why real experts are driven away from Wikipedia. If I spent half the time needed to maintain Wikipedia articles, I wouldn't be able to maintain my expertise in the original subject to begin with.
No one is going to make a full time job of just babysitting one or two articles in perpetuity. Any solution that you propose has to scale to many hundreds if not thousands of articles, or it will just be ignored.
Try using CentOS for personal use. It's Free and bug-for-bug compatible with Redhat.
It's actually hard to find anything wrong with the results. Erdos is one of the greatest mathematicians of all time. I work in applied mathematics (cryptography) and some of my work relies on his discoveries. I'm not going to exaggerate and say he invented the internet, but there is foundational material in computer science that derives from his findings. I'm personally glad that Erdos took amphetamines, regardless of whether he depended on it. His drug use harmed at most one man, compared to the six billion others in the world who benefited from his work.
Also, you'd be hard pressed to argue that amphetamine use was harmful to Erdos. He lived a long life.
Both you and the GP are correct. Li-ion batteries degrade over time no matter what, but they degrade least quickly when kept at 40% charge.
You misunderstand the nature of the backdoor. Yes, discrete logarithm is very hard, but the inverse problem (exponentiation) is very easy. The NSA could have very easily produced the point via exponentiation, in which case they know the backdoor. For anyone else other than the NSA, accessing the backdoor requires computing a discrete logarithm.
It's a bit like factoring integers vs. multiplying integers. Factoring is very hard, but you can easily backdoor a factoring-based scheme without factoring anything just by picking the primes in secret, and presenting the product as if it were the original integer.
Sure, you can boycott DRM hardware, to a point, but at some point you have no choice. For example, DVI monitors are limited in resolution, and if you want to upgrade to HDMI, all HDMI monitors come with DRM. Also, what choice do you have, if all hardware by law must support DRM?
Let's look at the facts. Mozilla is a highly profitable organization. You would think that Mozilla could afford to spend at least a little money on hiring Thunderbird developers. Yet in reality Mozilla has done the opposite: they have completely abandoned Thunderbird.
Why? Because of money.
The vast majority of Mozilla's income comes from Google. One of Google's main products is Gmail. Thunderbird competes with Gmail. So it makes sense that Google wants Thunderbird dead. Of course, they're not going to announce their intentions in a press release, but in reality that's exactly what's going on. Announcements like this one only make their plan more obvious than before.
This kind of anti-competitive behavior is exactly why most Slashdot readers hate Microsoft. Why is Google getting a free pass here?
You won't be able to gather any more data for English, because English only has a few hundred irregular verbs to begin with, and the study already accounted for all of them. It would indeed be interesting to compare English with other languages, but there the problem is that few languages have as many irregular verbs as English, and most of the ones that do (i.e. Latin, Italian) have more than one family of regular verbs, making direct comparison difficult.
I'm a mathematician, not a linguist, and to me the article is quite newsworthy, even though the mathematics used in the study (that is, statistics) lies outside my research area. It's possible that the majority of linguists (such as you) may not be able to appreciate the novelty of this discovery, because they lack the mathematical background to evaluate the relative strength of this particular statistical characterization compared with other ones that have appeared in analogous studies.
The computation carried out in the article is not merely a matter of "ability", nor is it fair to characterize it as a simulation. If you read the original article, you'll find that they derive the square-root law for verb decay using two intrinsically different approaches (three if you count the zipfian extrapolation). The most dramatic difference is that the first approach does not on the historical dates of Old and Middle English, whereas the second one does. There is no mathematics-based reason in general why these two approaches would even yield a square-root law at all. The fact that they both produce the same square root law, with coefficient values within three percent of each other, is actually (from a mathematics perspective) quite shocking. It indicates very strongly that their quantification of decay rates is right and likely to hold for future centures (much more strongly than if they had merely presented one statistical fit, which is the norm in most articles).
A crucial observation is that the data set that they use is not self-selected or biased in any way -- it is simply a complete list of all the irregular verbs in the English language for which documentation of the Old English forms could be found. In my experience it is quite rare for a naturally occurring data set such as this one to conform to two distinct statistical models in exactly the same way.