GSM in much of Europe? Spectrum licenses were granted on the condition that they were used with a specific protocol or set of protocols. GSM is patented, so you can only produce mobile phones for use in Europe if you pay the relevant fees.
No, it doesn't. The only major software license I'm aware of that is completely locked out is GPLv3 software with the patent clause.
Off the top of my head, GPLv2 (clause 7), LGPL, Apache 2, MPL, and CDDL also have clauses that prevent redistribution if doing so would require a patent license that you do not have the right to infinitely sublicense. In fact, only BSD style licenses don't have this kind of requirement, and then then the requirement for a separate patent license rather defeats the point: you receive a copyright license to redistribute the BSD licensed code, but if you can't exercise this right without separately buying a patent license then it's largely irrelevant.
I dunno, ask Mozilla. They make millions per year, yet they act like they can't even pay the FREE license for H.264. That's nothing but pure ideology.
What free license? There is no free license for H.264 players. Mozilla can't pay the MPEG-LA license, because the licenses that their code is distributed under (MPL, GPL and LGPL) require them to give everyone who receives a copy of the code a license to redistribute the code, with no time limit. Mozilla would therefore have to continue to buy patent licenses, right up to the fee cap, until the patents expired or be committing copyright infringement (they don't own all of the code that they distribute, so they can't summarily change the licensing terms).
Uh, really? Q4 2001 sales figures show more than twice as many Android phones being sold in Q4 of 2010 than 2011. If people are abandoning the platform in droves, a lot more are flocking there to replace them.
It takes a tiny fraction of a second with any vaguely modern OS to generate a bitmap glyph for any character in a given size and typeface. There is no point in pre-rendering them for every font, just generate them on demand and cache them.
Take a look at the history of Islam. Mohammad specifically prohibited converting people by force. Two years later, armies under his command attacked a city (that he had a peace treaty with, by the way) and gave everyone a choice: convert to Islam or die.
Christianity started to be used as a justification for atrocities shortly after the Roman emperors converted. Islam was like that from the start.
Probably not, but now two unrelated sites can still cooperate to identify you between them. If you log in anywhere that uses your OpenID address as a public identifier then so can any crawlers. As I said in another post, a well-designed version of OpenID would have the authentication server provide no more assurance than that the same person attempting to log in twice was the same person. It would not provide any information that could tie this person to another account on an unrelated system.
There's probably a generation of programmers that haven't really grasped the concept of various operations having a cost.
The problem here is that they are taught high-level languages. In C, it's pretty easy to look at some code and figure out - roughly - how much it will cost. In Java, it's a lot harder. In JavaScript, not only is it even harder, the cost can vary dramatically between implementations. If you know an assembly language or C, then you can easily think 'how is this actually implemented?' when you write something in a high-level language. If you don't, then it's very hard to perform this translation. And guess what has been slowly disappearing from curricula for the last two decades...
No. You want a separate RAM cache, with its own battery, that can persist between crashes and phone power cycling. The idea would be that changes would be stored there and later flushed to the flash if they had not been superseded after a while. You want something that has the same persistence guarantees as a flushed write to flash, but at a lower cost. Having a small amount of RAM (32MB would probably be enough) with a separate - small - battery or capacitor. When the phone loses power, it would write its contents out to the flash. This is not a new idea - server RAID controllers do the same thing.
You're assuming that the majority of what is on screen is from raster sources and not vectors. Both Android and iOS make heavy use of vectors throughout the UI and, while these do place a heavy load on the CPU and GPU for scaling, they place very little load on the flash. It's also worth noting that the flash write times are the main problem - read is usually fast enough.
It's depressing, sure, but I've read it twice and didn't find it particularly hard going either time - the first time was when I was 14, so I probably missed some nuance the first time around. That said, I wouldn't recommend anyone read more than one Orwell per year unless they have access to prescription antidepressants. If you think 1984 is depressing, try Burmese Days or Keep the Aspidistra Flying...
As I said, the requirement is 'balance of probability'. You make the claim and provide evidence, the other side has to show that it is improbable. It's up to the judge or jury do then weigh the evidence and see which is more likely...
I'm sure Google loves OpenID. Now, not only do they get to track IPs and cookies from the various sites that use Google Ads or Analytics, they get to correlate multiple online identities on unrelated sites and build a detailed profile about a person. OpenID, sadly, isn't dead, but that doesn't mean it isn't a bloody stupid idea.
This really bugs me too. If a site lets my browser store the password, then I store it in the keychain, where it is encrypted and protected by an ACL so nothing other than the browser can get at it. If a site doesn't let my browser store a password then I also store it in the keychain, but now I transfer it to the browser via the clipboard where any app can see it.
I'd like to see a standard password database storage format
The storage format isn't the problem, it's the API. The OS X keychain provides a key-value store where each entry has an ACL tied to a particular version of a program. If you modify a program binary, you must reauthorise it. If I enter a password in Safari, Opera can only access it if I explicitly grant Opera permission for that password. How the passwords are stored is of secondary importance - the important part is that no program - especially not a web browser, which downloads and runs untrusted code - should be accessing the store directly.
OpenID doesn't solve the privacy problem that it allows you to easily track someone across sites. Without it, I can easily use a different username and password for every password. My browser already stores all of these, so login is pretty much a solved problem. No site can tell what my account is on another site (unless I'm stupid enough to use gravatar or similar). With OpenID, it is trivial to tie together two online identities.
A well-designed single sign on system would have an authentication server provide no more information than a value indicating that two consecutive authentication attempts are the same person. It should not be tied to something like an email address (at least on the site's side - that's fine on the authentication provider's side).
I'm pretty sure that Chrome on OS X uses the Keychain, so you can use the generated passwords from any other browser that does (i.e. Safari or Opera - I think FireFox can with an extension, but it defaults to reinventing the wheel). The Keychain can also generate passwords and tell you the strength of passwords, but for some reason Apple has not exposed this functionality in the browser.
In a civil suit, the burden of evidence is 'the balance of probability'. If you can show that your browser sends the header if a particular setting is enabled and that you have enabled that setting, then the other party would have to show that it was not sent in a specific case, or provide some counter evidence. In a criminal case, the standard is 'beyond reasonable doubt', so they would just have to show that it was possible that it was not sent.
I've not tried pass through, but I run VLC on a FreeBSD box connected to a 5.1 analogue speaker system and it has no problems decoding DD and DTS and sending the audio to the correct speakers. It actually worked out of the box, as I discovered after spending an hour searching for documentation to find out how to make it work before considering actually testing it...
I just saw it for the first time, launching VLC 2.0. No idea what it does - the OS has its own font cache, I don't know why VLC feels the need to be special in that regard...
Apps in the App Store run in sandboxed mode. This means that they can't access the filesystem, other than files selected in the file chooser (which runs in a separate process and passes in file descriptor rights). The Mac Keychain means that each password has its own ACL and you must explicitly grant an application the right to each password it accesses. For an application to leak a serious amount of data, it must compromise the sandbox - not impossible (there have been holes found in it in the past) but a lot harder than just sneaking some malicious code into the app...
Oracle didn't discontinue the Opterons, but they also haven't invested anything in new product development in that area. At this stage, they're basically a legacy product line for people locked in to paying Sun / Oracle for everything.
Labour of course will accuse Tories of *.*, they'll join in with any criticism of the Tories because that's all that pillock Milliband ever does.
Really? I thought he mostly blamed the Liberal Democrats for allowing the Tories to do things. He rarely has the balls to accuse the Tories of anything directly...
Slashdot Mirror
GSM in much of Europe? Spectrum licenses were granted on the condition that they were used with a specific protocol or set of protocols. GSM is patented, so you can only produce mobile phones for use in Europe if you pay the relevant fees.
No, it doesn't. The only major software license I'm aware of that is completely locked out is GPLv3 software with the patent clause.
Off the top of my head, GPLv2 (clause 7), LGPL, Apache 2, MPL, and CDDL also have clauses that prevent redistribution if doing so would require a patent license that you do not have the right to infinitely sublicense. In fact, only BSD style licenses don't have this kind of requirement, and then then the requirement for a separate patent license rather defeats the point: you receive a copyright license to redistribute the BSD licensed code, but if you can't exercise this right without separately buying a patent license then it's largely irrelevant.
I dunno, ask Mozilla. They make millions per year, yet they act like they can't even pay the FREE license for H.264. That's nothing but pure ideology.
What free license? There is no free license for H.264 players. Mozilla can't pay the MPEG-LA license, because the licenses that their code is distributed under (MPL, GPL and LGPL) require them to give everyone who receives a copy of the code a license to redistribute the code, with no time limit. Mozilla would therefore have to continue to buy patent licenses, right up to the fee cap, until the patents expired or be committing copyright infringement (they don't own all of the code that they distribute, so they can't summarily change the licensing terms).
Ah, yes, but you would say that if you were a sock puppet wouldn't you. I bet you weigh the same as a duck too...
Actually, people are abandoning Android in droves
Uh, really? Q4 2001 sales figures show more than twice as many Android phones being sold in Q4 of 2010 than 2011. If people are abandoning the platform in droves, a lot more are flocking there to replace them.
It takes a tiny fraction of a second with any vaguely modern OS to generate a bitmap glyph for any character in a given size and typeface. There is no point in pre-rendering them for every font, just generate them on demand and cache them.
if you had actually read "Keep The Aspidistra Flying", you would have been aware that it has an optimistic ending
Seriously? *SPOILER ALERT*
It ends with him abandoning his ideals and accepting the mainstream idea of what he should be. If you find that optimistic, then I feel sorry for you.
Take a look at the history of Islam. Mohammad specifically prohibited converting people by force. Two years later, armies under his command attacked a city (that he had a peace treaty with, by the way) and gave everyone a choice: convert to Islam or die.
Christianity started to be used as a justification for atrocities shortly after the Roman emperors converted. Islam was like that from the start.
Probably not, but now two unrelated sites can still cooperate to identify you between them. If you log in anywhere that uses your OpenID address as a public identifier then so can any crawlers. As I said in another post, a well-designed version of OpenID would have the authentication server provide no more assurance than that the same person attempting to log in twice was the same person. It would not provide any information that could tie this person to another account on an unrelated system.
There's probably a generation of programmers that haven't really grasped the concept of various operations having a cost.
The problem here is that they are taught high-level languages. In C, it's pretty easy to look at some code and figure out - roughly - how much it will cost. In Java, it's a lot harder. In JavaScript, not only is it even harder, the cost can vary dramatically between implementations. If you know an assembly language or C, then you can easily think 'how is this actually implemented?' when you write something in a high-level language. If you don't, then it's very hard to perform this translation. And guess what has been slowly disappearing from curricula for the last two decades...
No. You want a separate RAM cache, with its own battery, that can persist between crashes and phone power cycling. The idea would be that changes would be stored there and later flushed to the flash if they had not been superseded after a while. You want something that has the same persistence guarantees as a flushed write to flash, but at a lower cost. Having a small amount of RAM (32MB would probably be enough) with a separate - small - battery or capacitor. When the phone loses power, it would write its contents out to the flash. This is not a new idea - server RAID controllers do the same thing.
This is true, however Android doesn't suck noticeably more than any of its competitors, just in different way.
You're assuming that the majority of what is on screen is from raster sources and not vectors. Both Android and iOS make heavy use of vectors throughout the UI and, while these do place a heavy load on the CPU and GPU for scaling, they place very little load on the flash. It's also worth noting that the flash write times are the main problem - read is usually fast enough.
It's depressing, sure, but I've read it twice and didn't find it particularly hard going either time - the first time was when I was 14, so I probably missed some nuance the first time around. That said, I wouldn't recommend anyone read more than one Orwell per year unless they have access to prescription antidepressants. If you think 1984 is depressing, try Burmese Days or Keep the Aspidistra Flying...
As I said, the requirement is 'balance of probability'. You make the claim and provide evidence, the other side has to show that it is improbable. It's up to the judge or jury do then weigh the evidence and see which is more likely...
I'm sure Google loves OpenID. Now, not only do they get to track IPs and cookies from the various sites that use Google Ads or Analytics, they get to correlate multiple online identities on unrelated sites and build a detailed profile about a person. OpenID, sadly, isn't dead, but that doesn't mean it isn't a bloody stupid idea.
This really bugs me too. If a site lets my browser store the password, then I store it in the keychain, where it is encrypted and protected by an ACL so nothing other than the browser can get at it. If a site doesn't let my browser store a password then I also store it in the keychain, but now I transfer it to the browser via the clipboard where any app can see it.
I'd like to see a standard password database storage format
The storage format isn't the problem, it's the API. The OS X keychain provides a key-value store where each entry has an ACL tied to a particular version of a program. If you modify a program binary, you must reauthorise it. If I enter a password in Safari, Opera can only access it if I explicitly grant Opera permission for that password. How the passwords are stored is of secondary importance - the important part is that no program - especially not a web browser, which downloads and runs untrusted code - should be accessing the store directly.
OpenID doesn't solve the privacy problem that it allows you to easily track someone across sites. Without it, I can easily use a different username and password for every password. My browser already stores all of these, so login is pretty much a solved problem. No site can tell what my account is on another site (unless I'm stupid enough to use gravatar or similar). With OpenID, it is trivial to tie together two online identities.
A well-designed single sign on system would have an authentication server provide no more information than a value indicating that two consecutive authentication attempts are the same person. It should not be tied to something like an email address (at least on the site's side - that's fine on the authentication provider's side).
I'm pretty sure that Chrome on OS X uses the Keychain, so you can use the generated passwords from any other browser that does (i.e. Safari or Opera - I think FireFox can with an extension, but it defaults to reinventing the wheel). The Keychain can also generate passwords and tell you the strength of passwords, but for some reason Apple has not exposed this functionality in the browser.
In a civil suit, the burden of evidence is 'the balance of probability'. If you can show that your browser sends the header if a particular setting is enabled and that you have enabled that setting, then the other party would have to show that it was not sent in a specific case, or provide some counter evidence. In a criminal case, the standard is 'beyond reasonable doubt', so they would just have to show that it was possible that it was not sent.
I've not tried pass through, but I run VLC on a FreeBSD box connected to a 5.1 analogue speaker system and it has no problems decoding DD and DTS and sending the audio to the correct speakers. It actually worked out of the box, as I discovered after spending an hour searching for documentation to find out how to make it work before considering actually testing it...
I just saw it for the first time, launching VLC 2.0. No idea what it does - the OS has its own font cache, I don't know why VLC feels the need to be special in that regard...
Apps in the App Store run in sandboxed mode. This means that they can't access the filesystem, other than files selected in the file chooser (which runs in a separate process and passes in file descriptor rights). The Mac Keychain means that each password has its own ACL and you must explicitly grant an application the right to each password it accesses. For an application to leak a serious amount of data, it must compromise the sandbox - not impossible (there have been holes found in it in the past) but a lot harder than just sneaking some malicious code into the app...
Oracle didn't discontinue the Opterons, but they also haven't invested anything in new product development in that area. At this stage, they're basically a legacy product line for people locked in to paying Sun / Oracle for everything.
Labour of course will accuse Tories of *.*, they'll join in with any criticism of the Tories because that's all that pillock Milliband ever does.
Really? I thought he mostly blamed the Liberal Democrats for allowing the Tories to do things. He rarely has the balls to accuse the Tories of anything directly...