The Amdahl's law is a gross oversimplification. It assumes that every problem consists of a part that is unavoidably sequential, while the rest is parallelizable in an unlimited way with no overhead.
The reality is that almost every problem is parallelizable (with a few notable exceptions like the lexicographically minimal shortest path or constructing the DFS numbering of a graph where we do not know whether an efficient parallel algorithm exist), but problems differ in overhead imposed by their parallelization.
Nonsense. The only negative externalities are those caused by producing electricity and those are much better handled by a tax on electricity, not by silly regulation of light bulbs.
The important thing is that the government should not dictate people what light sources are efficient and useful for what purpose. If CFLs are so efficient that they are less expensive to use, the people will take advantage of that sooner or later and there is no need for the government to force feed them the truth. In this case, the government has overstepped its mandate too far.
Also, there are many uses of incandescent bulbs where they cannot be easily replaced by CFLs -- e.g., if you need to regulate the light output continuously, or if they are very often turned on and off, or simply if the heat produced is desired.
I do not claim that MS does not need to test their patches thoroughly. I only told that at least in the cases I have observed, Windows updates produced at least one order of magnitude more problems that all Linux updates I have seen. It is a sign that whatever testing MS does, it is not effective.
As of legal trouble: If there were any real legal liability for MS's software defects, MS would be already bankrupt a dozen times and you can choose whether for their bugs in general, the failures of products to meet their specs (remember the Windows Vista hardware requirements fiasco?), or negligence to fix security bugs.
Just last week Ubuntu released two kernel updates (at least for x86-64) for 10.4. I can't help but think the reason is that there was a flaw in the first release that forced a second.
Sure, such cases happen, but you still have the choice: either you prefer security even if it might cost stability in rare cases (which can be worked around by reverting to the previous version almost always), or you prefer stability, so you can wait a couple of days with applying the patch and check if an updated version is issued.
No, but unlike many others I prefer to present all the evidence I have. I have written "at most once", because in our case I do not really know whether the problem was related to the security update or not, because it disappeared quicker than I was able to find out its cause.
But even if it were a failure, one problem on a large amount of machines vs. many problems even on a small number of machines is still a strong case.
All the Windows installations I have seen broken were just the default install (unlike the Linux machines), so if the MS's QA process fails to discover such cases, it's hopelessly broken anyway.
Sorry, but it seems that you are a little bit confused about the real cause. First of all, the blame lies on MS for creating the bug. Secondly, a responsible vendor should fix a security hole as quickly as possible, because security bugs are rarely discovered by a single person only. It is highly probable that the same bug is already being expoited by the black hat hackers in the wild. Five days is more than enough for the vast majority of security problems and delaying the fix is completely irresponsible. IMHO, MS should stop complaining and fix their processes instead.
In addition to that, it seems that MS has never replied to the researcher. Responsible vendors do that and they even cooperate with the researchers on the possible fixes. Most researchers treat such vendors very respectfully, but they hardly have any understanding for vendors who expect that they can delay security fixes for months and ignore the input from the security community.
It may seem that so, but the reality seems to disagree. Most Linux distributions release security updates within a day or two after the vulnerability is announced and while I maintain dozens of Linux machines, I had witnessed a security update breaking something at most once. On the other hand, I have seen problems caused by Windows updates countless times.
Evolution doesn't explain the beginning of time, doesn't explain order or complexity, nothing cannot come nothing, chaos does not create order, etc.
Contrary to popular belief, chaos can very well create order. In fact, you can rigorously prove that any system which is large enough must contain regular parts, however chaotic it may seem at the global scale. See the Ramsey Theorem for a classical example.
This would be an upper limit if you knew that the hash function has uniform distribution. However, nobody is able to prove anything like that for the SHA family. We have a plenly of evidence supporting uniformity, but definitely not a proof.
This could work if the load of your machine is of a single type only. However, many people tend to use their workstations for both interactive desktop programs and lots of number crunching on the background. Therefore they need a scheduler which performs well on both "server" and "desktop" style load at the same moment.
OK, this is easier than I thought, sorry for spreading misinformation.
But it still far from being optimal. You can easily present the basic details of the certificate in the first step and let the user confirm it from there if he wishes.
Yes, I can do it, but you wouldn't win a usability contest with that, I guess.
First I have to export the certificate to a file, then find the right option in the browser's UI to import it back. Compare it with just hitting "accept" when I first access the router (and check that the certificate is proper, for example by ensuring that only my machine is connected to it).
I need to check the fingerprint only once. Then the browser caches the certificate and since that time it always verifies the identity of the server properly.
Or, maybe you are claiming that SSH is completely insecure because it does not have certificate authorities?;-)
Still, it is no reason for making the user believe that HTTPS without authentication is less secure than HTTP (which is what the current behavior of FF3 very much suggests).
Showing the yellow address bar and padlock icon for HTTPS with proper authentication, and keeping it white for both HTTP and unauthenticated HTTPS would solve the problem of users being mislead just fine.
Nobody speaks about blindly trusting self-signed certs. I speak about properly asking the user if the particular cert is to be trusted. There is a plenty of cases where the user can make a perfectly valid decision that the certificate is trusted.
Also, I have to disagree with you: while self-signed certs do not prevent prying eyes in general, they do in specific cases. Claiming that they never do is another form of security theater.
Still, even if you assume that they don't, HTTPS with such certificates protects against all passive attacks, so it is obviously better than plain HTTP. Of course, it should be indicated differently than HTTPS with an authenticated certificate.
Sorry, but there is no need to invent any other mechanism for encrypted, but not authenticated, traffic -- SSL with a self-signed certificate is a perfectly fit tool for that.
Repeatedly claiming that HTTPS with an invalid certificate is less secure than plain HTTP does not make it true.
In many cases, people are perfectly happy with SSL just keeping the traffic from the prying eyes of others and ensuring that the server is the same server that handled the site for the first time.
Except for a couple of well-known sites, the domain name is just a name and it does not carry any other meaning (e.g., a verified relationship to any physical entity). So it really does not matter if you are talking to the proper xyz.com or some other xyz.com, as long as it is still the same site.
Slashdot Mirror
Besides, if you have a 1000-line Java program and a 10000-line COBOL program doing the same task, which is going to have less bugs per line? :-)
Technical mistake? I would call it utter incompetence of the investigators, who do not understand the difference between a domain and its subdomain.
The Amdahl's law is a gross oversimplification. It assumes that every problem consists of a part that is unavoidably sequential, while the rest is parallelizable in an unlimited way with no overhead. The reality is that almost every problem is parallelizable (with a few notable exceptions like the lexicographically minimal shortest path or constructing the DFS numbering of a graph where we do not know whether an efficient parallel algorithm exist), but problems differ in overhead imposed by their parallelization.
Nonsense. The only negative externalities are those caused by producing electricity and those are much better handled by a tax on electricity, not by silly regulation of light bulbs.
Also, there are many uses of incandescent bulbs where they cannot be easily replaced by CFLs -- e.g., if you need to regulate the light output continuously, or if they are very often turned on and off, or simply if the heat produced is desired.
Can you cite any recent one?
I was speaking about upgrades, not fresh installs.
Agreed, but fortunately we often have the choice to avoid the Godzillas and King Kongs of this age and choose an OS which has real security support :-)
I do not claim that MS does not need to test their patches thoroughly. I only told that at least in the cases I have observed, Windows updates produced at least one order of magnitude more problems that all Linux updates I have seen. It is a sign that whatever testing MS does, it is not effective.
As of legal trouble: If there were any real legal liability for MS's software defects, MS would be already bankrupt a dozen times and you can choose whether for their bugs in general, the failures of products to meet their specs (remember the Windows Vista hardware requirements fiasco?), or negligence to fix security bugs.
Debian, Suse, Gentoo, ...
Sure, such cases happen, but you still have the choice: either you prefer security even if it might cost stability in rare cases (which can be worked around by reverting to the previous version almost always), or you prefer stability, so you can wait a couple of days with applying the patch and check if an updated version is issued.
No, but unlike many others I prefer to present all the evidence I have. I have written "at most once", because in our case I do not really know whether the problem was related to the security update or not, because it disappeared quicker than I was able to find out its cause. But even if it were a failure, one problem on a large amount of machines vs. many problems even on a small number of machines is still a strong case.
All the Windows installations I have seen broken were just the default install (unlike the Linux machines), so if the MS's QA process fails to discover such cases, it's hopelessly broken anyway.
Sorry, but it seems that you are a little bit confused about the real cause. First of all, the blame lies on MS for creating the bug. Secondly, a responsible vendor should fix a security hole as quickly as possible, because security bugs are rarely discovered by a single person only. It is highly probable that the same bug is already being expoited by the black hat hackers in the wild. Five days is more than enough for the vast majority of security problems and delaying the fix is completely irresponsible. IMHO, MS should stop complaining and fix their processes instead.
In addition to that, it seems that MS has never replied to the researcher. Responsible vendors do that and they even cooperate with the researchers on the possible fixes. Most researchers treat such vendors very respectfully, but they hardly have any understanding for vendors who expect that they can delay security fixes for months and ignore the input from the security community.
It may seem that so, but the reality seems to disagree. Most Linux distributions release security updates within a day or two after the vulnerability is announced and while I maintain dozens of Linux machines, I had witnessed a security update breaking something at most once. On the other hand, I have seen problems caused by Windows updates countless times.
Evolution doesn't explain the beginning of time, doesn't explain order or complexity, nothing cannot come nothing, chaos does not create order, etc.
Contrary to popular belief, chaos can very well create order. In fact, you can rigorously prove that any system which is large enough must contain regular parts, however chaotic it may seem at the global scale. See the Ramsey Theorem for a classical example.
Could anycast work at all with TCP connections?
This would be an upper limit if you knew that the hash function has uniform distribution. However, nobody is able to prove anything like that for the SHA family. We have a plenly of evidence supporting uniformity, but definitely not a proof.
This could work if the load of your machine is of a single type only. However, many people tend to use their workstations for both interactive desktop programs and lots of number crunching on the background. Therefore they need a scheduler which performs well on both "server" and "desktop" style load at the same moment.
OK, this is easier than I thought, sorry for spreading misinformation.
But it still far from being optimal. You can easily present the basic details of the certificate in the first step and let the user confirm it from there if he wishes.
Yes, I can do it, but you wouldn't win a usability contest with that, I guess.
First I have to export the certificate to a file, then find the right option in the browser's UI to import it back. Compare it with just hitting "accept" when I first access the router (and check that the certificate is proper, for example by ensuring that only my machine is connected to it).
I need to check the fingerprint only once. Then the browser caches the certificate and since that time it always verifies the identity of the server properly.
;-)
Or, maybe you are claiming that SSH is completely insecure because it does not have certificate authorities?
Still, it is no reason for making the user believe that HTTPS without authentication is less secure than HTTP (which is what the current behavior of FF3 very much suggests).
Showing the yellow address bar and padlock icon for HTTPS with proper authentication, and keeping it white for both HTTP and unauthenticated HTTPS would solve the problem of users being mislead just fine.
Nobody speaks about blindly trusting self-signed certs. I speak about properly asking the user if the particular cert is to be trusted. There is a plenty of cases where the user can make a perfectly valid decision that the certificate is trusted.
Also, I have to disagree with you: while self-signed certs do not prevent prying eyes in general, they do in specific cases. Claiming that they never do is another form of security theater.
Still, even if you assume that they don't, HTTPS with such certificates protects against all passive attacks, so it is obviously better than plain HTTP. Of course, it should be indicated differently than HTTPS with an authenticated certificate.
Sorry, but there is no need to invent any other mechanism for encrypted, but not authenticated, traffic -- SSL with a self-signed certificate is a perfectly fit tool for that. Repeatedly claiming that HTTPS with an invalid certificate is less secure than plain HTTP does not make it true.
In many cases, people are perfectly happy with SSL just keeping the traffic from the prying eyes of others and ensuring that the server is the same server that handled the site for the first time. Except for a couple of well-known sites, the domain name is just a name and it does not carry any other meaning (e.g., a verified relationship to any physical entity). So it really does not matter if you are talking to the proper xyz.com or some other xyz.com, as long as it is still the same site.