No, you're wrong! Why do you even think that? There are many reasons that you can re-implement a closed API, among them for interoperability purposes. That covers most things you would want to do with an API, actually.
Because in order to re-implement an API, it is necessary to copy almost verbatim the definitions of the functions and other entities that make up the public interface of the API.
Sure, you *can* change around things such as the names of the variables in the function arguments, and can define things in a different order, but those are meaningless changes. There's little flexibility beyond this.
It's not so much that options are evil, but options do significantly complicate testing, making production bugs more likely.
Every option that can be chosen separately is a different configuration of the software that must be tested to ensure it's working properly. So if you have, for example, 10 binary options, that's 1024 different browser configurations to test. If you have 20, then you're at more than a million options, which is just impossible to test thoroughly.
It's definitely possible to reduce all of this difficulty through compartmentalization and good coding and testing practices, but more options will always result in more opportunity for user-facing bugs to happen to end-users. The benefit, of course, is that the kinds of bugs that are a result of various options can typically be worked-around by selecting different options. But it's still a significant increase in testing cost, and one major worry is that users will simply move on to a different piece of software rather than search around for a way to work around the issue.
I really hope this interpretation doesn't stand, because it will make it impossible to reimplement any closed API without licensing agreements. It's definitely the case that there are many possible ways to organize an API, but a ruling of this kind limits competition.
I know that very similar patents are allowed as a matter of course for physical interfaces, e.g. Apple's lightning connector or razors with replaceable heads. But honestly I feel that the markets would be better off all-around if such interface patents were disallowed across the board.
I don't understand how a DMCA takedown complaint can result in royalties going to somebody else as the takedown complaint results in removal of the video.
Yes, somewhat higher CO2 concentrations can help plants to grow if everything else stays constant. But everything else isn't constant.
Most places that currently grow food stand to face much more frequent drought conditions with a higher global average temperature, and the effect of those droughts far outweighs the mild impact of higher CO2 concentrations.
The specific impacts are regional, of course, but globally the impact of global warming is to drastically reduce crop yields. Some of this will be offset by areas further north becoming usable for farmland (such as in Canada and Siberia), but overall production is still expected to be reduced by global warming.
I think it's very possible (even reasonable) to have a language which provides the option between different sorts of memory management. My point was mainly that it's really difficult to modify Java to use reference-counted memory management instead of the current garbage collection scheme. It's also going to be very difficult to move Android off of Java.
Currently Android developers can help the memory management situation by using the NDK and using C or C++, but I don't think that's very common. These languages tend to result in more complicated code than Java.
Because quite a lot of how the language is designed rests upon garbage collection assumptions. Try to do this with Java, and first you'll have a really difficult time coming up with a coherent set of rules for destruction of objects so that developers can understand the lifetimes of their objects. Then you'll have the problem that any existing codebase is likely to break in unpredictable and difficult-to-debug ways (e.g. sometimes objects will be destroyed before they should be, leading to crashes or security nightmares as references point to the wrong objects, other times objects won't be destroyed creating memory leaks).
There's also the fact that garbage collectors tend to require much more memory in order to maintain performance than reference-counting schemes. This is a huge part of the reason why Android requires so much more RAM than iOS.
This also means that performance just tanks on devices that rely on GC as memory gets close to full, which can lead to really nasty experiences.
I really think that making use of a garbage-collected language as the primary language in embedded devices is a bad, bad idea all-around. I still prefer Android to iOS, but I really wish that Google could undo the decision to use Java. I have a hard time believing that Google using Swift for Android is at all likely.
It might require a little bit of sophistication to create the software that would make an image respond to the requested gesture, but this would pave the way for credentials to be stolen (permanently) by just taking a picture of a person.
Bidding should be utterly irrelevant to client bandwidth. There's no reason for the web browser to have any knowledge of the bidding process at all. It just puts in a request for the ad, and gets content back. As for page load, that's largely a design issue. The website should always load ad content asynchronously after the main page content is loaded.
I think you've got some rose tinted glasses there. Crappy ads have been a big problem on the Internet for well over a decade. Pop-ups were once a much bigger problem than they are today, particularly as web browsers have gotten much better at blocking them. So were brightly-colored flashing ads. The days of flash ads are quickly coming to a close (which should dramatically reduce malware served through ads). Malware has always been a problem, and not I've restricted to ads. I'm not sure whether the ad experience overall has been getting better or worse, but there's no doubt that adds on the Internet have always been a sore spot, even as they have enabled an explosion of great content.
There are two main groups of content that would be hurt by this. First are the relatively poor people who host smallish websites such as some blogs that, were it not for advertising revenue, would be unable to afford to keep their sites running. Second are the somewhat larger content providers who are attempting to make their living on the Internet. This would include many people running websites with medium to large amount of traffic, as well as small businesses. They generally would much rather be focused on creating content than worry about the minutiae of serving ads.
Why do you think that would be the case? Sites like Buzzfeed have quite enough resources to manage the ads on their platform. The downside is that they'd have a lot less time and resources to deal with said ads than a third-party ad provider would, so you'd be even more likely to end up with shit ads and malware.
1. How do you propose funding websites, if not with ads?
2. There's no reason for ad bidding to take more than a few milliseconds. If it takes longer, then the intermediary supplying the ad has broken software. I'm pretty sure this is a complete non-issue.
I doubt it. I'd be willing to bet that killing born babies is so deeply ingrained in our psyche by evolution that it won't happen within a huge number of generations (read: thousands), perhaps longer.
Genetic counseling is already reasonably common, and has most of the ethical concerns of "designer babies" already. Parents use genetic counseling most frequently to avoid heritable genetic disorders or chromosomal abnormalities.
I have a hard time seeing how the trials required to even begin gene editing on human embryos that are brought to term could ever be justified, though. Modifying an embryo who is otherwise expected to become a healthy human just isn't something that I can see any ethics board allowing, as there are very likely to be significant side effects.
This is generally not a concern for most countries. Usually people move to a new country in the hope of finding work. Social programs just help get them into the workforce faster.
Sure, I suppose a sudden, large-scale influx could be a problem. But this usually just doesn't happen. And it would pay for itself many times over if the country would simply borrow the money for getting the new immigrants settled.
Analytics like this might be capable of informing professors what doesn't work: if students aren't paying any attention to something, then either the professor should find a way to get them to pay attention to it, or should just drop it from the curriculum entirely.
They won't, of course, provide any information about what actually does work. But at least some things that don't work could potentially be eliminated.
I'm not sure what you think this means for cold fusion. In the Sun, fusion only occurs at the very high temperatures and pressures near its core. Fusion does not occur throughout the vast majority of the volume of the Sun. The whole point of cold fusion is to try to produce fusion without those high temperatures or pressures.
The BLS says the number of programmers will drop by 26,500 over the next ten years, while the number of software developers will increase by 186,600. I.e., this story is bullshit and the writer should have paid closer attention to the statistics. The number of people writing software as their job in the US is expected to increase pretty dramatically.
Slashdot Mirror
No, you're wrong! Why do you even think that? There are many reasons that you can re-implement a closed API, among them for interoperability purposes. That covers most things you would want to do with an API, actually.
Because in order to re-implement an API, it is necessary to copy almost verbatim the definitions of the functions and other entities that make up the public interface of the API.
Sure, you *can* change around things such as the names of the variables in the function arguments, and can define things in a different order, but those are meaningless changes. There's little flexibility beyond this.
It's not so much that options are evil, but options do significantly complicate testing, making production bugs more likely.
Every option that can be chosen separately is a different configuration of the software that must be tested to ensure it's working properly. So if you have, for example, 10 binary options, that's 1024 different browser configurations to test. If you have 20, then you're at more than a million options, which is just impossible to test thoroughly.
It's definitely possible to reduce all of this difficulty through compartmentalization and good coding and testing practices, but more options will always result in more opportunity for user-facing bugs to happen to end-users. The benefit, of course, is that the kinds of bugs that are a result of various options can typically be worked-around by selecting different options. But it's still a significant increase in testing cost, and one major worry is that users will simply move on to a different piece of software rather than search around for a way to work around the issue.
I really hope this interpretation doesn't stand, because it will make it impossible to reimplement any closed API without licensing agreements. It's definitely the case that there are many possible ways to organize an API, but a ruling of this kind limits competition.
I know that very similar patents are allowed as a matter of course for physical interfaces, e.g. Apple's lightning connector or razors with replaceable heads. But honestly I feel that the markets would be better off all-around if such interface patents were disallowed across the board.
I don't understand how a DMCA takedown complaint can result in royalties going to somebody else as the takedown complaint results in removal of the video.
Yes, somewhat higher CO2 concentrations can help plants to grow if everything else stays constant. But everything else isn't constant.
Most places that currently grow food stand to face much more frequent drought conditions with a higher global average temperature, and the effect of those droughts far outweighs the mild impact of higher CO2 concentrations.
The specific impacts are regional, of course, but globally the impact of global warming is to drastically reduce crop yields. Some of this will be offset by areas further north becoming usable for farmland (such as in Canada and Siberia), but overall production is still expected to be reduced by global warming.
For more detailed info, see here.
I think it's very possible (even reasonable) to have a language which provides the option between different sorts of memory management. My point was mainly that it's really difficult to modify Java to use reference-counted memory management instead of the current garbage collection scheme. It's also going to be very difficult to move Android off of Java.
Currently Android developers can help the memory management situation by using the NDK and using C or C++, but I don't think that's very common. These languages tend to result in more complicated code than Java.
I don't think there's any reason to believe that the Apache license alone means they'd be safe from patent suits.
Because quite a lot of how the language is designed rests upon garbage collection assumptions. Try to do this with Java, and first you'll have a really difficult time coming up with a coherent set of rules for destruction of objects so that developers can understand the lifetimes of their objects. Then you'll have the problem that any existing codebase is likely to break in unpredictable and difficult-to-debug ways (e.g. sometimes objects will be destroyed before they should be, leading to crashes or security nightmares as references point to the wrong objects, other times objects won't be destroyed creating memory leaks).
There's also the fact that garbage collectors tend to require much more memory in order to maintain performance than reference-counting schemes. This is a huge part of the reason why Android requires so much more RAM than iOS.
This also means that performance just tanks on devices that rely on GC as memory gets close to full, which can lead to really nasty experiences.
I really think that making use of a garbage-collected language as the primary language in embedded devices is a bad, bad idea all-around. I still prefer Android to iOS, but I really wish that Google could undo the decision to use Java. I have a hard time believing that Google using Swift for Android is at all likely.
Every vulnerability is zero-day until a patch comes out addressing it.
It might require a little bit of sophistication to create the software that would make an image respond to the requested gesture, but this would pave the way for credentials to be stolen (permanently) by just taking a picture of a person.
Somehow I don't think this is a good idea.
Bidding should be utterly irrelevant to client bandwidth. There's no reason for the web browser to have any knowledge of the bidding process at all. It just puts in a request for the ad, and gets content back. As for page load, that's largely a design issue. The website should always load ad content asynchronously after the main page content is loaded.
I think you've got some rose tinted glasses there. Crappy ads have been a big problem on the Internet for well over a decade. Pop-ups were once a much bigger problem than they are today, particularly as web browsers have gotten much better at blocking them. So were brightly-colored flashing ads. The days of flash ads are quickly coming to a close (which should dramatically reduce malware served through ads). Malware has always been a problem, and not I've restricted to ads. I'm not sure whether the ad experience overall has been getting better or worse, but there's no doubt that adds on the Internet have always been a sore spot, even as they have enabled an explosion of great content.
There are two main groups of content that would be hurt by this. First are the relatively poor people who host smallish websites such as some blogs that, were it not for advertising revenue, would be unable to afford to keep their sites running. Second are the somewhat larger content providers who are attempting to make their living on the Internet. This would include many people running websites with medium to large amount of traffic, as well as small businesses. They generally would much rather be focused on creating content than worry about the minutiae of serving ads.
Why do you think that would be the case? Sites like Buzzfeed have quite enough resources to manage the ads on their platform. The downside is that they'd have a lot less time and resources to deal with said ads than a third-party ad provider would, so you'd be even more likely to end up with shit ads and malware.
Placing the burden on content providers will just push smaller content providers out. I can see no benefit to this.
Furthermore, centralized ad content distributors can do a lot more to combat malware than can smaller content providers.
For at least Google ads, you can turn off user tracking for ads: https://www.google.com/setting...
1. How do you propose funding websites, if not with ads? 2. There's no reason for ad bidding to take more than a few milliseconds. If it takes longer, then the intermediary supplying the ad has broken software. I'm pretty sure this is a complete non-issue.
I doubt it. I'd be willing to bet that killing born babies is so deeply ingrained in our psyche by evolution that it won't happen within a huge number of generations (read: thousands), perhaps longer.
Genetic counseling is already reasonably common, and has most of the ethical concerns of "designer babies" already. Parents use genetic counseling most frequently to avoid heritable genetic disorders or chromosomal abnormalities.
I have a hard time seeing how the trials required to even begin gene editing on human embryos that are brought to term could ever be justified, though. Modifying an embryo who is otherwise expected to become a healthy human just isn't something that I can see any ethics board allowing, as there are very likely to be significant side effects.
This is generally not a concern for most countries. Usually people move to a new country in the hope of finding work. Social programs just help get them into the workforce faster.
Sure, I suppose a sudden, large-scale influx could be a problem. But this usually just doesn't happen. And it would pay for itself many times over if the country would simply borrow the money for getting the new immigrants settled.
Yes, the answer is most definitely to increase immigration, and in particular to be less selective about immigration.
But the US really isn't inviting people in. It's almost as bad on immigration policy as Europe is.
Analytics like this might be capable of informing professors what doesn't work: if students aren't paying any attention to something, then either the professor should find a way to get them to pay attention to it, or should just drop it from the curriculum entirely.
They won't, of course, provide any information about what actually does work. But at least some things that don't work could potentially be eliminated.
I'm not sure what you think this means for cold fusion. In the Sun, fusion only occurs at the very high temperatures and pressures near its core. Fusion does not occur throughout the vast majority of the volume of the Sun. The whole point of cold fusion is to try to produce fusion without those high temperatures or pressures.
The BLS says the number of programmers will drop by 26,500 over the next ten years, while the number of software developers will increase by 186,600. I.e., this story is bullshit and the writer should have paid closer attention to the statistics. The number of people writing software as their job in the US is expected to increase pretty dramatically.