For someone who has been in IT for 30 years, you don't seem to know what you're talking about. If your phone is capable of receiving calls, then your phone software security is important. This goes even if you have the Wifi radio turned off (most do not), had the Bluetooth radio turned off (most do not), and had the USB charging port stuffed with silly putty. Older feature phones were less of a problem because they were effectively useless at anything but making phone calls, so hackers were less interested in targeting them. Today it's different.
You're playing the game of "I'm not important enough to hack", as though anyone running a exploit kit actually sits down and says "no I recognize that IP address and he's a loser....won't spend the 300ms it takes to crack his phone."
As someone who has clients in one of those areas I can tell you: you have to contact your state legislator to get ordinary service orders completed. I'm not even kidding.
AT&T only wants to do wireless now. From where I'm sitting, it looks like they are stripping the wireline side bare and are waiting for a regulatory opportunity to spin off the carcus.
Wrong. Your cell phone broadcasts telemetry all the time, whether you request it or not. That's how cell phones affiliate to towers. Your preferences that you set on the phone only affect data available to the apps running on the phone, and not the firmware itself.
Additionally, the carrier usually has the ability to remotely enable or disable certain hardware on the phone without user intervention, via cellular firmware drivers. This is because the same CPU that runs your apps is also interacting with the cellular radio, which is under the carrier's control, and not you.
It's worth noting that Node.js has really one build manager: NPM. For why that is relevant, see this: http://www.theregister.co.uk/2...
NPM is fairly new, and is undergoing the growing pains of becoming a major code distribution platform. Part of this is finding out why it's a bad idea to allow repositories to instantly disappear, and also why its an even worse idea for the previously used namespace to be reused by a different maintainer, especially in the absence of other security measures like code signing. Putting your project under the Node umbrella means you will need to adapt as they gradually figure these things out.
The problem with wars is that they come home. We've raised multiple generations to become ruthless in order to fight massive wars, and then act surprised when they treat offices, newspapers, churches, and courtrooms as battlefields, and judges, legislators, and citizens as enemies or collateral. When you are raised to be a hammer, every person that gets in your way is a nail. That's what the "team player" nonsense is all about---the US isn't the team they're talking about.
They don't like Node because it runs in a single thread and basically forces you to use async IO or risk blocking the thread which is serving incoming requests. On most frameworks you can just to kick the user request to a background thread and do your IO synchronously there. Problem is, thread per user doesn't scale for fairly high connection counts when you are IO bound (which most web apps are). However, doing async programming is hard, because the flow of control is inverted and doesn't really follow the flow of code on the page and because callbacks become hairy when you have to chain several async operations together (what happens if a call never returns, returns with exception, etc). How do you compose the results of several async operations when the results may come in our of order?
JS, as a language, doesn't provide you the tools to compose those things easily. There are third party libraries which try to fix that, such as async.js, bluebird and promises API, or Rx. You have to use futures/observables/promises to compose async tasks or things get out of hand in a hurry.
Using lots of closed source software sounds good on paper. On some cases it makes sense if you are doing something in a niche area and closed source is far more robust. However, consider what you give up:
If something goes wrong, you have no tools to figure out why. That means a support agreement for as long as you rely on it, in perpetuity.
You can only incorporate said software in ways permitted by the copyright holder. Unlike open source systems where you can fork the code if there is a problem with the upstream developer, in the closed source case you must accept any ongoing license changes as they occur or stop using their code.
Security back ports are impossible.
The ownership of closed source systems changes frequently just like in open source. However, you are completely at the mercy of whoever acquires them for reasons explained above.
The fact that software is closed source (meaning you have no way of knowing code is infringing) does not protect you as a user from patent infringement claims, unless the license agreement offers such indemnity.
Porting to new hardware architectures often requires virtualization or emulation (such as on mobile). Cross compiling isn't possible without vendor support.
You are often restricted when it comes to deployment (management of key servers etc)
In the case of zero-cost closed source, the price actually bring paid is usually consenting to various types of surveillance.
In closed source software, file storage formats are often secret as well, in some cases protected by patents. If you stop using the software in this case, you no longer have a non-infringing method of accessing your own data.
Set to make plenty of money...
Clearly not, if it was worth a complete reimplementation to avoid license fees. I think this is a case where you set up a $100,00 toll road and get mad when people pave their own roads to bypass it.
All GPL code is copyright by definition. If it wasn't then GPL would not be enforceable under US law. GPL is simply the legal agreement under which the attached code is distributed.
I'm not going to list the contents of maven central in a slashdot thread for you. By the way, the so-called Android API already bundles some third-party libraries (such as Apache HttpComponents) although you may not realize it.
Just because it's an ISO or IEEE standard doesn't mean you can legally implement it without obtaining licenses. The same thing also holds for many telcos standards.
BS. That's precisely why it was done. It was done so existing Java third-party libraries (of which there are a huge amount) could be leveraged in Android applications without much rework needed. Google would not have had to even create Dalvik at all, had the JVM had the necessary efficiency to operate on memory and clock constrained mobile platforms. The problem is that Sun and later Oracle killed the golden goose with overly restrictive licensing. If they can go after Google for Dalvik, they can also sue Apache for making Tomcat, various open source byte-code optimizers, and virtually any competing database vendor which can run Java stored procedures.
This lawsuit is why Java will never replace standardized languages like C, because the owner of the language has legally encumbered the technology to the point that it is a minefield.
People have been warning about this for decades. What I'm surprised about isn't that it happened, but rather that it took this long.
You're not supposed to put classified material on the State Department email server either. That's why the separate classified network is there.
You could make an argument that too many things were classified, but some of the stuff that went over Hillary's server were secret by anyone's definition and should never have touched an internet facing box, ever.
The reason she did that was because the NSA would not give her a portable device (which she could access from a plane, or at the Clinton offices) with connectivity to the more secure system, and rather than fight it out, she went around the agency and had subordinates copy classified material across systems. Were we more or less secure than having a classified endpoint located at Clinton Global Initiative? I don't have an answer to that.
They're called source maps. They let you see the source in the developer tools without suffering the performance penalty of downloading unminified in production. Making source maps available fixes that complaint. I think the bigger issue is that the Copyright Office doesn't actually write their own code, and the vendors often don't provide unminified versions that can be source mapped.
Tech companies used to have no problem complying with reasonable intercept requests. The reason was because they knew those intercepts were used for actual law enforcement. Sometime in the last 15 years that changed. Government employees concerned with information awareness now wear two hats: a law enforcement hat, and a geopolitical dominance hat. Until the 21st century, the people wearing those hats worked in different offices. Not anymore. Hayden and Comey have both said essentially the same thing: that when you're in the job, it's a moral obligation to use every tool at your disposal. There is no practical difference between lawful intercept and foreign intelligence intercept. If the NSA knows the FBI has lawful intercept capability into any phone, they are morally obligated to gain access to it. If the FBI knows the NSA has a fiber access capability, they are obligated to apply for access. The marriage of military and police means every tool of one is available to the other. Given how quickly US arms fall into the hands of "freedom fighters" like FSA, how long do you think it would take before iPhone intercept capability was being used by Colombian political candidates and Mexican cartels? At least a mortar round actually has to be manufactured. Copying code requires no material components at all.
I believe that's the heart of this debate that no one wants to talk about.
Slashdot Mirror
For someone who has been in IT for 30 years, you don't seem to know what you're talking about. If your phone is capable of receiving calls, then your phone software security is important. This goes even if you have the Wifi radio turned off (most do not), had the Bluetooth radio turned off (most do not), and had the USB charging port stuffed with silly putty. Older feature phones were less of a problem because they were effectively useless at anything but making phone calls, so hackers were less interested in targeting them. Today it's different. You're playing the game of "I'm not important enough to hack", as though anyone running a exploit kit actually sits down and says "no I recognize that IP address and he's a loser....won't spend the 300ms it takes to crack his phone."
As someone who has clients in one of those areas I can tell you: you have to contact your state legislator to get ordinary service orders completed. I'm not even kidding. AT&T only wants to do wireless now. From where I'm sitting, it looks like they are stripping the wireline side bare and are waiting for a regulatory opportunity to spin off the carcus.
Wrong. Your cell phone broadcasts telemetry all the time, whether you request it or not. That's how cell phones affiliate to towers. Your preferences that you set on the phone only affect data available to the apps running on the phone, and not the firmware itself. Additionally, the carrier usually has the ability to remotely enable or disable certain hardware on the phone without user intervention, via cellular firmware drivers. This is because the same CPU that runs your apps is also interacting with the cellular radio, which is under the carrier's control, and not you.
It's worth noting that Node.js has really one build manager: NPM. For why that is relevant, see this: http://www.theregister.co.uk/2... NPM is fairly new, and is undergoing the growing pains of becoming a major code distribution platform. Part of this is finding out why it's a bad idea to allow repositories to instantly disappear, and also why its an even worse idea for the previously used namespace to be reused by a different maintainer, especially in the absence of other security measures like code signing. Putting your project under the Node umbrella means you will need to adapt as they gradually figure these things out.
You mean you haven't heard the app-Appy guy? He must be on vacation.
The fact that lazy evaluation and monads are an add-on library and not a core part of the language syntax means we are in promise hell.
Answer, because JavaScript programmers are what the programmer mills are churning out. Technology choice is only loosely coupled to merits.
You forgot you can also modify constants.
The problem with wars is that they come home. We've raised multiple generations to become ruthless in order to fight massive wars, and then act surprised when they treat offices, newspapers, churches, and courtrooms as battlefields, and judges, legislators, and citizens as enemies or collateral. When you are raised to be a hammer, every person that gets in your way is a nail. That's what the "team player" nonsense is all about---the US isn't the team they're talking about.
Official investigations are quietly under way
The keyword there is quietly. Condemnation of critics is loud. Affirmation of critics is quiet.
They don't like Node because it runs in a single thread and basically forces you to use async IO or risk blocking the thread which is serving incoming requests. On most frameworks you can just to kick the user request to a background thread and do your IO synchronously there. Problem is, thread per user doesn't scale for fairly high connection counts when you are IO bound (which most web apps are). However, doing async programming is hard, because the flow of control is inverted and doesn't really follow the flow of code on the page and because callbacks become hairy when you have to chain several async operations together (what happens if a call never returns, returns with exception, etc). How do you compose the results of several async operations when the results may come in our of order? JS, as a language, doesn't provide you the tools to compose those things easily. There are third party libraries which try to fix that, such as async.js, bluebird and promises API, or Rx. You have to use futures/observables/promises to compose async tasks or things get out of hand in a hurry.
Using lots of closed source software sounds good on paper. On some cases it makes sense if you are doing something in a niche area and closed source is far more robust. However, consider what you give up: If something goes wrong, you have no tools to figure out why. That means a support agreement for as long as you rely on it, in perpetuity. You can only incorporate said software in ways permitted by the copyright holder. Unlike open source systems where you can fork the code if there is a problem with the upstream developer, in the closed source case you must accept any ongoing license changes as they occur or stop using their code. Security back ports are impossible. The ownership of closed source systems changes frequently just like in open source. However, you are completely at the mercy of whoever acquires them for reasons explained above. The fact that software is closed source (meaning you have no way of knowing code is infringing) does not protect you as a user from patent infringement claims, unless the license agreement offers such indemnity. Porting to new hardware architectures often requires virtualization or emulation (such as on mobile). Cross compiling isn't possible without vendor support. You are often restricted when it comes to deployment (management of key servers etc) In the case of zero-cost closed source, the price actually bring paid is usually consenting to various types of surveillance. In closed source software, file storage formats are often secret as well, in some cases protected by patents. If you stop using the software in this case, you no longer have a non-infringing method of accessing your own data.
Groklaw died with attorney-client privilege.
That's fair. It only copies the design mistakes of C++. The good parts they mostly managed to avoid.
Set to make plenty of money... Clearly not, if it was worth a complete reimplementation to avoid license fees. I think this is a case where you set up a $100,00 toll road and get mad when people pave their own roads to bypass it.
All GPL code is copyright by definition. If it wasn't then GPL would not be enforceable under US law. GPL is simply the legal agreement under which the attached code is distributed.
I'm not going to list the contents of maven central in a slashdot thread for you. By the way, the so-called Android API already bundles some third-party libraries (such as Apache HttpComponents) although you may not realize it.
Just because it's an ISO or IEEE standard doesn't mean you can legally implement it without obtaining licenses. The same thing also holds for many telcos standards.
BS. That's precisely why it was done. It was done so existing Java third-party libraries (of which there are a huge amount) could be leveraged in Android applications without much rework needed. Google would not have had to even create Dalvik at all, had the JVM had the necessary efficiency to operate on memory and clock constrained mobile platforms. The problem is that Sun and later Oracle killed the golden goose with overly restrictive licensing. If they can go after Google for Dalvik, they can also sue Apache for making Tomcat, various open source byte-code optimizers, and virtually any competing database vendor which can run Java stored procedures. This lawsuit is why Java will never replace standardized languages like C, because the owner of the language has legally encumbered the technology to the point that it is a minefield. People have been warning about this for decades. What I'm surprised about isn't that it happened, but rather that it took this long.
You're not supposed to put classified material on the State Department email server either. That's why the separate classified network is there. You could make an argument that too many things were classified, but some of the stuff that went over Hillary's server were secret by anyone's definition and should never have touched an internet facing box, ever. The reason she did that was because the NSA would not give her a portable device (which she could access from a plane, or at the Clinton offices) with connectivity to the more secure system, and rather than fight it out, she went around the agency and had subordinates copy classified material across systems. Were we more or less secure than having a classified endpoint located at Clinton Global Initiative? I don't have an answer to that.
The firewall just got 10 feet higher.
So when will Google sue Sue Googe?
They're called source maps. They let you see the source in the developer tools without suffering the performance penalty of downloading unminified in production. Making source maps available fixes that complaint. I think the bigger issue is that the Copyright Office doesn't actually write their own code, and the vendors often don't provide unminified versions that can be source mapped.
Tech companies used to have no problem complying with reasonable intercept requests. The reason was because they knew those intercepts were used for actual law enforcement. Sometime in the last 15 years that changed. Government employees concerned with information awareness now wear two hats: a law enforcement hat, and a geopolitical dominance hat. Until the 21st century, the people wearing those hats worked in different offices. Not anymore. Hayden and Comey have both said essentially the same thing: that when you're in the job, it's a moral obligation to use every tool at your disposal. There is no practical difference between lawful intercept and foreign intelligence intercept. If the NSA knows the FBI has lawful intercept capability into any phone, they are morally obligated to gain access to it. If the FBI knows the NSA has a fiber access capability, they are obligated to apply for access. The marriage of military and police means every tool of one is available to the other. Given how quickly US arms fall into the hands of "freedom fighters" like FSA, how long do you think it would take before iPhone intercept capability was being used by Colombian political candidates and Mexican cartels? At least a mortar round actually has to be manufactured. Copying code requires no material components at all. I believe that's the heart of this debate that no one wants to talk about.
Only losers, wonks, and junior aides go to the Library. Cool kids go to fundraisers.