As you know, being free is a matter of freedom, not price. Myself I do not think that complaining at Adobe is likely to help the situation (as hinted at in what I wrote). But it's clear that the release of a binary blob Flash player for x86_64 is not going to solve the problems of Flash at a single stroke. There is much more to do.
Out of interest, what do you consider the smallest possible user base that any concession should be made with regard to support?
I don't think Itanic workstation users who want to watch YouTube are a significant user base; just making a general point that x86_64 != 64-bit. This being Slashdot, I guess I could have left it unsaid, since many others made the same point.
In general I'm all for dropping esoteric crap and focusing on the most important systems, as long as people have freedom to muck around with the code and port it to their platform of choice if they're willing to make the effort themselves. That's not the case with a binary blob, so arguably it should be held to slightly higher standards.
We now have Java and Flash on 64-bit. No more reason to bitch.
Java is free but Flash is not (gnash and swfdec are getting there, but still not good enough for everyday use). And x86_64 is not the only 64-bit platform; what about Sparc and Itanic users, for example?
A binary blob for x86_64 is nice, I guess, but better would be for Adobe to give a bit of help to the projects trying to make a free implementation of Flash. So please continue to bitch, if you think that helps.
Remember that Novell helped Microsoft get OOXML approved and Novell forked OpenOffice.org as soon as it moved to GPLv3.
That is interesting. So you mean that Novell's go-oo is always going to stay GPLv2? I know that upstream is GPLv3 as of OOo 3.0.
As for the patent covenant with Moonlight, this applies only to the patented media formats (MPEG video and audio, etc) which cannot be legally played with free software in the USA. Microsoft distributes binary-only codecs which can be used free of charge. You can use Moonlight without them, and it is entirely free software in that case.
Novell differs from SCO in that this time around there is a trail of receipts showing that yes you do owe M$money for their products
I'm glad to hear there is solid evidence in the form of a 'trail of receipts' showing that paying Microsoft is necessary. I was beginning to think your post was just another uninformed rant, but you have reassured me. Just one thing: do you think you could post this 'chain of receipts' and other evidence that you may have? Of course, I believe you immediately that the whole existence of Novell and free software projects such as Mono and OpenOffice is merely a conspiracy by Microsoft, co-ordinated by Miguel de Icaza as a kind of Gollum figure. But some other people (fools that they are!) might not be so trusting. I have the same problems myself when I try to explain that the Iraq War was secretly started by Barack Obama disguised as a nun. So if you'd be so good as to provide this evidence that you have?
It's one thing to have a packaging standard for third-party applications which install in their own directory and require well-known libraries defined in the Linux Standard Base. I agree, there should be a cross-distro standard for installing these programs (and there is: LSB defines a package format, the only problem is getting the third-party vendors to use it). But the Nvidia drivers are not just any old application; they want to overwrite standard system files and otherwise mess around with things. It's unreasonable to expect all distributions to support that.
BTW, the moderation of your comment as 'Troll' is a sad reflection on the Linux-groupthink around here.
namely because they are still using the monkey-horde development technique, which is get a bunch of third-world programmers in a room and churn out very lackluster code, and then keep redeveloping it until it works "good enough"
Er, citation needed? Have you ever worked at Microsoft?
Actually, I tried the latest XaoS (it has improved a lot since ten years ago) and it does support a wide range of fractals, though not as many as gnofract4d.
I recently discovered gnofract4d and it reminds you that, whatever you think about CPU usage for web browsing or programming, computers still aren't fast enough:-p. It's like the old days when the first thing you'd do with that shiny new Pentium-66 workstation was to see how fast it could run Fractint. It seems we have to wait at least a decade for high-resolution fractals zoomed in real time. (There is XaoS but it has a limited choice of fractal types and needs to interpolate pixels. The answer may be to use GPU hardware, as FFFF does, but preferably using a compiler like Brahma that translates a high-level language to GPU calls.)
What happens is that during normal operation of any RAM there is a small chance that a particular bit will get flipped. Cosmic rays are often blamed as the culprit; of course if you overclock and overvolt your memory you increase the chance of errors, but even good quality RAM running within spec will get an incorrect bit every so often. If you use non-ECC memory there is no chance to spot this error; it just returns the wrong data. The old parity memory added one extra check bit for every eight bits, so most of the time it could detect (but not correct) a one-bit error. ECC stands for error correcting code (look it up on Wikipedia) meaning that if one individual bit is corrupted it can recover the correct data. If you are really unlucky and two bits in the same code word get corrupted at the same time then you still have problems, but that is unlikely.
If you are using non-ECC RAM then may be getting corrupted from time to time, but you don't notice.
Does this mean that AMD chips are now competitive on price-performance with Intel's? I mean for a fairly high-end desktop or server; obviously different considerations apply in the embedded or netbook market.
The LSB standard format is rpm v3 format, whereas all current distributions use a newer rpm (from one fork or another) and the old v3 archives are supported only as a legacy format for LSB. I think for political reasons they might rename it from 'rpm' to 'LSB package format' and make sure direct support for v3 packages is removed from rpm, then people wouldn't get so worked up about it somehow being unfair to Debian. No recent distribution actually uses LSB format packages natively.
No, my carrier is Vodafone UK, but that shouldn't matter too much since I am trying to ssh to a host inside my company's network via the 'enterprise' stuff (and I can http to that machine fine).
Mine is a BlackBerry 8310 v4.2.2.146 (Platform 2.5.0.16). I suppose that means it has OS 4.2. Which is strange, because I got it only recently (a few weeks before the Bold was announced).
I'm looking for how to upgrade, but it looks like you have to put the file on your PC and install the crappy Windows link software (which I have never touched) to get it onto the Blackberry. I've never understood why you can't just download a file directly on the handheld... then again, there are lots of stupdities in the mobile phone market which nobody understands.
The most useful Blackberry applications are Google Maps and Opera Mini (not a true web browser, so it can't access http servers on your local network, but works well for the public Internet).
Those are both proprietary. I have been looking for something to let me use the builtin GPS together with OpenStreetMap data, but after installing several different programs none of them works. I also couldn't get MidpSSH to work, although the payware ssh client from rovemobile.com is as good as could be expected given the tiny screen. (They also make an RDP client to which the same comments apply.)
Can someone explain what is the point of DNSsec? An https website already has its own certificate which authenticates you are talking with the right person, and https is designed to be secure without trusting DNS. If DNSsec had been widely implemented twenty years ago then secure protocols might have evolved in a different direction, but given where we are now, what problem does DNSsec solve?
Similarly if you use ssh then the server authenticates to you with its own keypair. You don't need to trust that DNS gives the right answer.
Is DNSsec just to stop denial of service attacks on the DNS infrastructure and trivial hijacking of insecure protocols like telnet and http?
The kind of 'almighty terrorist government' that decides to monitor your web browsing is far more likely to be the government of the USA or allied countries. And they can quite easily MITM your traffic if they want (do you really think that the NSA doesn't have copies of Verisign's root keypair?). If you are really concerned about that you need to exchange PGP keys in person and certainly not rely on a flimsy chain of trust running from Verisign through other crappy signing authorities to your browser.
On the other hand, what this article discusses is _routine_ surveillance of _everybody_. This would certainly become impossible with routine encryption of all traffic. MITM'ing all traffic (or even 1% of it) is infeasible for an ISP, exposes them to huge legal risks (no ISP wants to be listening in on banking transactions, especially as their own network is probably not that secure), and would quickly be noticed. That is not perfect but it is a hell of a lot better than having everything in plaintext.
I will not expend my energy telling them not only to check for the padlock-icon and HTTPS but also the fingerprint.
Obviously, routine encryption of traffic where you do not have a signed certificate from the other side should not display the padlock icon, the glowing green address bar, or other indicators of security.
It would be very easy for an ISP to perform man-in-the-middle attacks on supposedly secure sites which use self-signed certificates.
'Very easy' if you are a cryptographer, but very difficult in practice. The computer hardware costs would be high and ISPs do not have the technical expertise required. Furthermore, while snooping on plaintext connections just requires listening to the traffic as it passes, a MITM attack requires actively meddling with the data and pretending to be somebody else. This is far too much of a legal risk for any legitimate business like an ISP.
That's why it is wrong to say that unauthenticated but encrypted connections provide no more security than plaintext ones. Against a determined criminal who can break the law, this is largely true. But to keep honest people honest and stop ISPs and others routinely eavesdropping on conversations, it works very well.
It is certainly wrong to assert, as Firefox's current policy does, that an encrypted connection with a self-signed key is *less* secure than one in which all the data is sent in plaintext.
Yeah right, that covers about 15% of the users. For the other 85%, you have to write workarounds anyway, valid HTML or not.
Not really. It's 2008. Any web browser written in the last ten years is capable of displaying HTML4 pages correctly. OK, if you do advanced CSS stuff then there might be subtle differences in table border collapse properties or other arcana, but who really bothers with that? Most sites don't use or need anything advanced (and CSS degrades gracefully in pretty much every browser that doesn't support it). Javascript is another kettle of fish, of course, but here we're discussing HTML.
Rather than forcing millions of web content producers (which includes secretaries posting announcements on a company website and MySpace users) to spend hours and hours to learn all the silly syntax rules of four HTML dialects,
I agree, none of these people should have to learn HTML syntax rules, any more than a word processor user should have to learn Postscript syntax in order to print something. The advice to validate your HTML only applies if you are writing it by hand. If you use some web page tool, then obviously you rely on that tool to take care of escaping ampersands and other crap.
BTW, there are not four HTML dialects. The basic HTML grammar does not differ between browsers; again, we are not in the old days of Netscape 1.6 any more. You can write to the HTML standard and any browser that's not completely antique will render it just fine. There are differences in CSS and Javascript, but even those are not as great as they once were.
the developers of the handful of common HTML engines in browsers should simply agree on how nonstandard HTML is handled.
That would basically entail another standard - so these pages would no longer be considered nonstandard. It's not a bad idea, but when the agreement is reached and published you should still validate pages against the new, more tolerant standard, because there will still be some cases that are left undefined. (And your argument about 15% of the users would certainly apply in this case, because you'd have to wait for everyone to upgrade to one of these new browsers including the standard set of rules for handling bad HTML.) I would prefer not to wait for HTML5 or whatever, but check my web pages now to make sure they fit what was agreed over ten years ago.
One reason to validate is that if you write valid HTML, it will display according to the HTML standards on any browser that's not buggy. You can view it in your favourite browser (Firefox, Chrome, whatever) and be fairly sure it will work the same in anyone else's. If the HTML contains errors, then the browser must use heuristics to correct it, and these heuristics are not standardized. So it's a matter of luck whether it will work correctly in $random_browser. It probably will, and you can test it in various browsers and make assumptions about what the different HTML engines do, but I'd rather just fix the bug and move on. It's the same with compiler warnings in code: sure, there are false positives and most warnings do not indicate a hidden bug that will trip you up later, but it's usually better just to fix a warning, make sure you stay within the C language standard, and never see that warning again.
Your example is not of a case where prostitution was legalized, but of a case where it remained illegal but the police abdicated their responsibility to enforce the law. That is quite different.
If it were legal, prostitutes wouldn't need to be on the streets at all. They could set up premises, pay taxes, and be entitled to police protection just the same as any legitimate business. They wouldn't need pimps or to hide when a police car drove by.
Again, who is regulating these massage parlours? An ordinary business like a grocery store or a car parts factory cannot traffic people from China and keep them hostage. It would be difficult to explain to the tax authorities, health and safety inspections, the unions and all the rest of the framework society has developed to keep companies behaving responsibly. If nothing else, the customers would simply tell the police if they spotted something suspicious. So why doesn't it happen in San Francisco? Isn't it because these places are illegal and nobody who goes there wants the police to know about it? If prostitution were fully legalized then seedy backstreet massage parlours would soon be driven out of business by legitimate, clean, tax-paying and safe sex businesses. After all, which would you rather visit?
I fully agree that just turning a blind eye to breaking the law is not the right answer. If prostitution is illegal then that needs to be enforced vigorously, because often habitual lawbreaking in one area leads on to criminality elsewhere. So 'condoning prostitution' while keeping it legal is a bad idea; but legalizing prostitution is quite different.
I think the other poster is making a snarky point about the rescue of the banking system, and the support and pressure given by governments to banks across the world to make sure they continue lending.
Slashdot Mirror
As you know, being free is a matter of freedom, not price. Myself I do not think that complaining at Adobe is likely to help the situation (as hinted at in what I wrote). But it's clear that the release of a binary blob Flash player for x86_64 is not going to solve the problems of Flash at a single stroke. There is much more to do.
I don't think Itanic workstation users who want to watch YouTube are a significant user base; just making a general point that x86_64 != 64-bit. This being Slashdot, I guess I could have left it unsaid, since many others made the same point.
In general I'm all for dropping esoteric crap and focusing on the most important systems, as long as people have freedom to muck around with the code and port it to their platform of choice if they're willing to make the effort themselves. That's not the case with a binary blob, so arguably it should be held to slightly higher standards.
Java is free but Flash is not (gnash and swfdec are getting there, but still not good enough for everyday use). And x86_64 is not the only 64-bit platform; what about Sparc and Itanic users, for example?
A binary blob for x86_64 is nice, I guess, but better would be for Adobe to give a bit of help to the projects trying to make a free implementation of Flash. So please continue to bitch, if you think that helps.
That is interesting. So you mean that Novell's go-oo is always going to stay GPLv2? I know that upstream is GPLv3 as of OOo 3.0.
As for the patent covenant with Moonlight, this applies only to the patented media formats (MPEG video and audio, etc) which cannot be legally played with free software in the USA. Microsoft distributes binary-only codecs which can be used free of charge. You can use Moonlight without them, and it is entirely free software in that case.
Did you also remove any trace of Sun from your department? Sun also has a patent cross-licensing deal with Microsoft.
Come to think of it, did you remove all trace of Microsoft?
I'm glad to hear there is solid evidence in the form of a 'trail of receipts' showing that paying Microsoft is necessary. I was beginning to think your post was just another uninformed rant, but you have reassured me. Just one thing: do you think you could post this 'chain of receipts' and other evidence that you may have? Of course, I believe you immediately that the whole existence of Novell and free software projects such as Mono and OpenOffice is merely a conspiracy by Microsoft, co-ordinated by Miguel de Icaza as a kind of Gollum figure. But some other people (fools that they are!) might not be so trusting. I have the same problems myself when I try to explain that the Iraq War was secretly started by Barack Obama disguised as a nun. So if you'd be so good as to provide this evidence that you have?
It's one thing to have a packaging standard for third-party applications which install in their own directory and require well-known libraries defined in the Linux Standard Base. I agree, there should be a cross-distro standard for installing these programs (and there is: LSB defines a package format, the only problem is getting the third-party vendors to use it). But the Nvidia drivers are not just any old application; they want to overwrite standard system files and otherwise mess around with things. It's unreasonable to expect all distributions to support that.
BTW, the moderation of your comment as 'Troll' is a sad reflection on the Linux-groupthink around here.
Two words: ZFS.
Er, citation needed? Have you ever worked at Microsoft?
Actually, I tried the latest XaoS (it has improved a lot since ten years ago) and it does support a wide range of fractals, though not as many as gnofract4d.
I recently discovered gnofract4d and it reminds you that, whatever you think about CPU usage for web browsing or programming, computers still aren't fast enough :-p. It's like the old days when the first thing you'd do with that shiny new Pentium-66 workstation was to see how fast it could run Fractint. It seems we have to wait at least a decade for high-resolution fractals zoomed in real time. (There is XaoS but it has a limited choice of fractal types and needs to interpolate pixels. The answer may be to use GPU hardware, as FFFF does, but preferably using a compiler like Brahma that translates a high-level language to GPU calls.)
What happens is that during normal operation of any RAM there is a small chance that a particular bit will get flipped. Cosmic rays are often blamed as the culprit; of course if you overclock and overvolt your memory you increase the chance of errors, but even good quality RAM running within spec will get an incorrect bit every so often. If you use non-ECC memory there is no chance to spot this error; it just returns the wrong data. The old parity memory added one extra check bit for every eight bits, so most of the time it could detect (but not correct) a one-bit error. ECC stands for error correcting code (look it up on Wikipedia) meaning that if one individual bit is corrupted it can recover the correct data. If you are really unlucky and two bits in the same code word get corrupted at the same time then you still have problems, but that is unlikely.
If you are using non-ECC RAM then may be getting corrupted from time to time, but you don't notice.
Does this mean that AMD chips are now competitive on price-performance with Intel's? I mean for a fairly high-end desktop or server; obviously different considerations apply in the embedded or netbook market.
The LSB standard format is rpm v3 format, whereas all current distributions use a newer rpm (from one fork or another) and the old v3 archives are supported only as a legacy format for LSB. I think for political reasons they might rename it from 'rpm' to 'LSB package format' and make sure direct support for v3 packages is removed from rpm, then people wouldn't get so worked up about it somehow being unfair to Debian. No recent distribution actually uses LSB format packages natively.
No, my carrier is Vodafone UK, but that shouldn't matter too much since I am trying to ssh to a host inside my company's network via the 'enterprise' stuff (and I can http to that machine fine).
Mine is a BlackBerry 8310 v4.2.2.146 (Platform 2.5.0.16). I suppose that means it has OS 4.2. Which is strange, because I got it only recently (a few weeks before the Bold was announced).
I'm looking for how to upgrade, but it looks like you have to put the file on your PC and install the crappy Windows link software (which I have never touched) to get it onto the Blackberry. I've never understood why you can't just download a file directly on the handheld... then again, there are lots of stupdities in the mobile phone market which nobody understands.
The most useful Blackberry applications are Google Maps and Opera Mini (not a true web browser, so it can't access http servers on your local network, but works well for the public Internet).
Those are both proprietary. I have been looking for something to let me use the builtin GPS together with OpenStreetMap data, but after installing several different programs none of them works. I also couldn't get MidpSSH to work, although the payware ssh client from rovemobile.com is as good as could be expected given the tiny screen. (They also make an RDP client to which the same comments apply.)
Can someone explain what is the point of DNSsec? An https website already has its own certificate which authenticates you are talking with the right person, and https is designed to be secure without trusting DNS. If DNSsec had been widely implemented twenty years ago then secure protocols might have evolved in a different direction, but given where we are now, what problem does DNSsec solve?
Similarly if you use ssh then the server authenticates to you with its own keypair. You don't need to trust that DNS gives the right answer.
Is DNSsec just to stop denial of service attacks on the DNS infrastructure and trivial hijacking of insecure protocols like telnet and http?
The kind of 'almighty terrorist government' that decides to monitor your web browsing is far more likely to be the government of the USA or allied countries. And they can quite easily MITM your traffic if they want (do you really think that the NSA doesn't have copies of Verisign's root keypair?). If you are really concerned about that you need to exchange PGP keys in person and certainly not rely on a flimsy chain of trust running from Verisign through other crappy signing authorities to your browser.
On the other hand, what this article discusses is _routine_ surveillance of _everybody_. This would certainly become impossible with routine encryption of all traffic. MITM'ing all traffic (or even 1% of it) is infeasible for an ISP, exposes them to huge legal risks (no ISP wants to be listening in on banking transactions, especially as their own network is probably not that secure), and would quickly be noticed. That is not perfect but it is a hell of a lot better than having everything in plaintext.
Obviously, routine encryption of traffic where you do not have a signed certificate from the other side should not display the padlock icon, the glowing green address bar, or other indicators of security.
'Very easy' if you are a cryptographer, but very difficult in practice. The computer hardware costs would be high and ISPs do not have the technical expertise required. Furthermore, while snooping on plaintext connections just requires listening to the traffic as it passes, a MITM attack requires actively meddling with the data and pretending to be somebody else. This is far too much of a legal risk for any legitimate business like an ISP.
That's why it is wrong to say that unauthenticated but encrypted connections provide no more security than plaintext ones. Against a determined criminal who can break the law, this is largely true. But to keep honest people honest and stop ISPs and others routinely eavesdropping on conversations, it works very well.
It is certainly wrong to assert, as Firefox's current policy does, that an encrypted connection with a self-signed key is *less* secure than one in which all the data is sent in plaintext.
Not really. It's 2008. Any web browser written in the last ten years is capable of displaying HTML4 pages correctly. OK, if you do advanced CSS stuff then there might be subtle differences in table border collapse properties or other arcana, but who really bothers with that? Most sites don't use or need anything advanced (and CSS degrades gracefully in pretty much every browser that doesn't support it). Javascript is another kettle of fish, of course, but here we're discussing HTML.
I agree, none of these people should have to learn HTML syntax rules, any more than a word processor user should have to learn Postscript syntax in order to print something. The advice to validate your HTML only applies if you are writing it by hand. If you use some web page tool, then obviously you rely on that tool to take care of escaping ampersands and other crap.
BTW, there are not four HTML dialects. The basic HTML grammar does not differ between browsers; again, we are not in the old days of Netscape 1.6 any more. You can write to the HTML standard and any browser that's not completely antique will render it just fine. There are differences in CSS and Javascript, but even those are not as great as they once were.
That would basically entail another standard - so these pages would no longer be considered nonstandard. It's not a bad idea, but when the agreement is reached and published you should still validate pages against the new, more tolerant standard, because there will still be some cases that are left undefined. (And your argument about 15% of the users would certainly apply in this case, because you'd have to wait for everyone to upgrade to one of these new browsers including the standard set of rules for handling bad HTML.) I would prefer not to wait for HTML5 or whatever, but check my web pages now to make sure they fit what was agreed over ten years ago.
One reason to validate is that if you write valid HTML, it will display according to the HTML standards on any browser that's not buggy. You can view it in your favourite browser (Firefox, Chrome, whatever) and be fairly sure it will work the same in anyone else's. If the HTML contains errors, then the browser must use heuristics to correct it, and these heuristics are not standardized. So it's a matter of luck whether it will work correctly in $random_browser. It probably will, and you can test it in various browsers and make assumptions about what the different HTML engines do, but I'd rather just fix the bug and move on. It's the same with compiler warnings in code: sure, there are false positives and most warnings do not indicate a hidden bug that will trip you up later, but it's usually better just to fix a warning, make sure you stay within the C language standard, and never see that warning again.
Your example is not of a case where prostitution was legalized, but of a case where it remained illegal but the police abdicated their responsibility to enforce the law. That is quite different.
If it were legal, prostitutes wouldn't need to be on the streets at all. They could set up premises, pay taxes, and be entitled to police protection just the same as any legitimate business. They wouldn't need pimps or to hide when a police car drove by.
Again, who is regulating these massage parlours? An ordinary business like a grocery store or a car parts factory cannot traffic people from China and keep them hostage. It would be difficult to explain to the tax authorities, health and safety inspections, the unions and all the rest of the framework society has developed to keep companies behaving responsibly. If nothing else, the customers would simply tell the police if they spotted something suspicious. So why doesn't it happen in San Francisco? Isn't it because these places are illegal and nobody who goes there wants the police to know about it? If prostitution were fully legalized then seedy backstreet massage parlours would soon be driven out of business by legitimate, clean, tax-paying and safe sex businesses. After all, which would you rather visit?
I fully agree that just turning a blind eye to breaking the law is not the right answer. If prostitution is illegal then that needs to be enforced vigorously, because often habitual lawbreaking in one area leads on to criminality elsewhere. So 'condoning prostitution' while keeping it legal is a bad idea; but legalizing prostitution is quite different.
I think the other poster is making a snarky point about the rescue of the banking system, and the support and pressure given by governments to banks across the world to make sure they continue lending.
There's precedent: look for 'Microsoft HTML Document'.