You have to balance the cost of throwing away the code and processes you know against the benefit provided by the language. The whole point of the language is to make it easier to express logic. If switching is simply creating an artificial barrier without providing something substantial you are wasting your time.
That being said, there is a subtle shift going on in most languages and toolchains right now. It is a trend toward share-nothing actor based concurrent systems. The reason for this has to do with scalability and correctness. Thread-based concurrency does not scale as well as userspace lightweight FSMs, and maintaining correctness with shared state gets very difficult as the number of processors goes up and their caches get further apart on the chip. That's one reason NodeJS has taken off, because it implements a very lightweight concurrency model subject to certain limitations. Learn a language/toolset geared for this and it will be time well spent.
Another shift is toward functional progtamming. Most functional languages share similar characteristics, so if you get a firm grasp of one the others won't be too hard to pick up.
That's precisely the case. A vast majority of leaks you read about in the paper are sourced from government officials acting with full knowledge of their agency. The ones who are prosecuted arent targeted because of the nature of the info, they are prosecuted based on who it embarrassed. That's why the only person to serve time in jail regarding torture was the guy who exposed it. When it comes to topics the government is sensitive about, we have more of a kangaroo system than a real court.
Petraeus was the head of an US intelligence agency at the time. If you don't understand why US intelligence is relevant to information technology you haven't been paying attention for 15 years.
It depends on who they are a shill for. The merger is bad for Google, who has lobbied against it. As you know, Google was a big Obama supporter and has meetings at the White House on an almost weekly basis.
The fact that this is even a debate at the UN shows how far gone the entire institution is. Killer robots are pretty much the ultimate WMD, especially if their manufacture can also be automated.
If a backdoor key exists, then the company that created it must by law give it to any lawful government authority that requests it. For example, if a company does business in Saudi Arabia, and a backdoor key exists, they may be compelled under Saudi law to give that key to the Saudi's. If a company does business in Russia, they may be compelled by the Russian government to give them the key. That's the nature of a backdoor. You can't just give it to only one entity. And let's not forget about Gemalto. They have cellphone encryption keys for the SIM cards they produced, which were held on their servers so that law enforcement agencies could obtain backdoor access to cellular communications via the legal process. However, the NSA broke into their servers and stole all of their secret keys, and then used them to mass decrypt cellular traffic. That's a real example of key escrow in action, and it completely failed to protect anyone.
At least in the U.S., the launching of satellites is heavily regulated. That's because the same technology that is used to launch mini toaster satellites into orbit is the same tech used to launch high yield explosives into orbit. It isn't just about space junk. Its about dual use strategic weapons technology. If the FAA won't let people flying heli drones at 250 feet, there is no way they will allow ordinary citizens to put up a different kind of drone at LEO or even GSO.
In software, there is no way to do it "right". The only right way to do it is not do it at all. There are too many isomorphisms in software patents because they oftrn represent abstract mathematical concepts. It isn't reasonable to expect people to avoid infringing something which is a core truth of the universe.
MIcrosoft is already running a bunch of stuff on Linux in the Azure cloud. They recognize they are a minority player in the cloud space and they have to leverage technology that was designed to scale to large core counts, something they didn't do much of in Redmond historically. I actually do foresee a Microsoft-spin of Linux. Oracle is actually worse than Microsoft in many ways (NIH syndrome), and they have their own Linux distro now. It's all server-side though, so don't expect a Microsoft Linux desktop, ever. New NoC hardware architectures may end up making the whole Linux vs NT thing moot anyway from a technology point of view.
GPL != Open Source. They would never release any part of Windows under GPL, ever. For an entertaining read, go over the licensing agreement for the new "open source".NET core, and decide for yourself what is REALLY the cancer.
Private companies can still be bought out. It's just that they are not listed on public exchanges; they are controlled via private equity. Valve is rolling in cash most likely (they have low relative operating costs), which would make them a hard acquisition target, but it's not impossible. They are heavily concentrated in their Steam business, which could be sunk at any time by a wrong turn in patent litigation, and I doubt they have a patent portfolio large enough to force a potential opponent to cross-license. The resulting damages awarded by such a suit would be astronomical if successful, and given how much money Valve has made in the past it is only a matter of time before lawyers start showing up claiming irreparable harm. One bright side is that they are getting into the console business, which means hardware vendors would likely come to their aid in a suit of that kind (mutually assured destruction).
My point is that there are no guarantees, and most software licenses are barely deserving of the name anyway. I don't spend money on any product on Steam I am not okay with losing tomorrow, and neither should anyone else.
There is no reason why people should be making $30 a copy for compression software that does the same thing today that it did 20 years ago. There is a point where boxed licensing ceases to be about paying programmers and instead becomes rents taking. For software that is not widely used but is otherwise essential to a particular businesses competitive advantage I might agree. For software that is very mature, widely relied upon, and a fundamental building block of infrastructure, I think free software has advantages that proprietary stuff does not, and by virtue of business need being spread over a large group of people, you are more likely to get constructive contribution. The success of the Linux kernel project, Apache, GNU build tools, Xen hypervisor, Docker, and several Java application servers is a testament to that. If you do not have users who are engineers (I.e., you are running on Windows), then yeah, expect the code to suck, if not be downright malicious.
You mean like an embedded/portable device, or a server that operates in an environment where you want to recover quickly from loss of power (such as when a server gets power-killed via a Smart PDU due to a transient hardware/software fault detected by an external monitor), or a server in an auto-scaling VM environment.
The Linux kernel is monolithic because that's what runs efficiently on current processors. Microkernels have some nice features regarding safety, but they are slow. Doing stuff like filesystem access in the userspace involves a context switch, which means you leave the CPU cache in many cases. Linus had a big discussion with Tanennbaum over that. Microkernels are good theory, and I think they are the future of reliable operating systems. However, current widely available CPU hardware is not DESIGNED to run microkernels in a way that is cache-local. Operating systems have to work with the reality the hardware provides.
Mac OSX has a microkernel system, but Apple ended up having to move some userspace drivers into the microkernel for the same reason described above.
I disagree. Dependency management is hugely important for servers. That's the whole reason things like apt and rpm exist, to say nothing of orchestration and configuration management stuff like Puppet and Chef. The fact is servers are run by operators who usually wear many hats and don't have time to "muck around" with failed software upgrades because services didn't shut down/upgrade/restart in the correct order. That's all cool when you have 2 or 3 servers to manage. When you have 1000 servers and 100 of them are down it's a huge inconvenience to troubleshoot.
Actually, the reason "export strength" RSA even exists is because of U.S. law classifying long-key RSA the same as military hardware. In other words, you could be sent to prison for selling it outside the U.S. If the FBI/NSA had their way back in the 1990s, everyone would be using this weak kind of "security" today.
Rights were not granted by the Constitution. They were recognized. They pre-existed. People don't have those rights because they are Americans. They have those rights because they are human beings. If the government chooses not to recognize those rights then that is a choice, but it does not alter the fact that those rights exist. Otherwise, it would be impossible for a government
to be guilty of rights violations.
Yeah, they would not surveil Congress staff working for the Intelligence Oversight Committee, because you know, that's totally beyond the scope of what they do...
You want the impossible. You want communications you can trust without having to understand how they happen. The usual compromise is to the Other Guy TM take care of the security for you, whether that's a dumbed down interface or cloud hosted services. Everyone's already doing this: its called Google and Facebook. It turns out the Other Guy TM isn't always so great at protecting you in all situations. So now you're back to square one: how do I have secure comms without needing to understand what's happening?
ORM came around, which IMHO is a totally ass-backward way of dealing with a DB from an OO point-of-view.
That's because SQL is a really horrible language. If it was structured algebraically with real relational operators this sort of mapping would be trivial. Instead you must choose which vendor's butchering of the English language you would prefer to write your complex set logic operation in. I'm not even going to get into the query optimizer. Key-value stores I think are a stage of grieving over how screwed up relational DB's are today.
Also, clients demanded that we run stuff in J2EE containers and hence, that we write it in Java, which I still consider to have been a marketing exercise by Sun Microsystems to obtain more broad meaning for their ailing Spark CPU line (Java has always ran suspiciously better on *nix than any other platform). Little did they count on GNU/Linux taking over the server universe. We did go Java, but never liked it, and still consider it the result of brainwashing, and don't understand the need for all those extra layers. There is not one thing that the container does that the OS cannot do better, except packaging, and ever there, J2EE is "write once, debug everywhere" in the field and therefore of little real help.
Well, simply put, Java eats memory for breakfast, lunch, and dinner. It's not as bad as it used to be, but Java inherently uses more memory than some other "managed code" languages because of how heavily it relies on heap storage, which has to be GC'ed. When you have many Java applications running on the same box, it is useful to share heap storage so that you don't have a situation where a Java application dies due to inability to allocate heap when 30% of available RAM is allocated but not in use by other Java processes. Containers also do things like connection pooling (because database connections are slow to set up and the OS doesn't do that), thread pooling (because the OS takes a long time to spin up a thread compared to execution time for very short function calls), message dispatch (because FIFO's don't always do the job on a heavily loaded system), and supervision (because sysv init sucks and OS people tend to oppose more complete supervisors). Was J2EE too big? Yeah, but the business need was still there.
I don't believe in making development easier:
I don't either. A bunch of peasant rabble; the lot of them.
So you see, for me, the current situation with the traction of NoSQL and the immense opportunily (and necessity, IMHO) to make the server-side efficient and lean again (power is now a major cost in the data center, vs bandwidth) is really a lot of "back to the future".
The current situation with the traction of NoSQL has to do with the fact that there are limits to how you can scale an ACID-compliant relational database, particularly when the data store is distributed over a network. Most of NoSQL (I say most, not all) revolves around fancy key-value stores. Key-value stores (which do not enforce relational consistency) have the property that data can be distributed across multiple nodes and can be retrieved in sub-linear time via a hashing algorithm like CHORD. Web developers basically discovered that they didn't need all of the functions that SQL databases provided, and by relaxing a few ACID constraints they could scale out with commodity hardware. Relational database servers are actually pretty efficient given the constraints they operate under (with the exception of the query parser), but those constraints don't always make sense.
Dogs understand more than you think. They have been bred over a thousand years to better grasp human communication; they pay more attention than other canines to certain parts of the face, and pick up nonverbal cues that humans sometimes miss or ignore. They tend to be interested only in certain things, though, which some people mistake for lack of intelligence.
Slashdot Mirror
You have to balance the cost of throwing away the code and processes you know against the benefit provided by the language. The whole point of the language is to make it easier to express logic. If switching is simply creating an artificial barrier without providing something substantial you are wasting your time. That being said, there is a subtle shift going on in most languages and toolchains right now. It is a trend toward share-nothing actor based concurrent systems. The reason for this has to do with scalability and correctness. Thread-based concurrency does not scale as well as userspace lightweight FSMs, and maintaining correctness with shared state gets very difficult as the number of processors goes up and their caches get further apart on the chip. That's one reason NodeJS has taken off, because it implements a very lightweight concurrency model subject to certain limitations. Learn a language/toolset geared for this and it will be time well spent. Another shift is toward functional progtamming. Most functional languages share similar characteristics, so if you get a firm grasp of one the others won't be too hard to pick up.
That's precisely the case. A vast majority of leaks you read about in the paper are sourced from government officials acting with full knowledge of their agency. The ones who are prosecuted arent targeted because of the nature of the info, they are prosecuted based on who it embarrassed. That's why the only person to serve time in jail regarding torture was the guy who exposed it. When it comes to topics the government is sensitive about, we have more of a kangaroo system than a real court.
Petraeus was the head of an US intelligence agency at the time. If you don't understand why US intelligence is relevant to information technology you haven't been paying attention for 15 years.
It depends on who they are a shill for. The merger is bad for Google, who has lobbied against it. As you know, Google was a big Obama supporter and has meetings at the White House on an almost weekly basis.
There is. Its called a business account.
The fact that this is even a debate at the UN shows how far gone the entire institution is. Killer robots are pretty much the ultimate WMD, especially if their manufacture can also be automated.
If a backdoor key exists, then the company that created it must by law give it to any lawful government authority that requests it. For example, if a company does business in Saudi Arabia, and a backdoor key exists, they may be compelled under Saudi law to give that key to the Saudi's. If a company does business in Russia, they may be compelled by the Russian government to give them the key. That's the nature of a backdoor. You can't just give it to only one entity. And let's not forget about Gemalto. They have cellphone encryption keys for the SIM cards they produced, which were held on their servers so that law enforcement agencies could obtain backdoor access to cellular communications via the legal process. However, the NSA broke into their servers and stole all of their secret keys, and then used them to mass decrypt cellular traffic. That's a real example of key escrow in action, and it completely failed to protect anyone.
At least in the U.S., the launching of satellites is heavily regulated. That's because the same technology that is used to launch mini toaster satellites into orbit is the same tech used to launch high yield explosives into orbit. It isn't just about space junk. Its about dual use strategic weapons technology. If the FAA won't let people flying heli drones at 250 feet, there is no way they will allow ordinary citizens to put up a different kind of drone at LEO or even GSO.
In software, there is no way to do it "right". The only right way to do it is not do it at all. There are too many isomorphisms in software patents because they oftrn represent abstract mathematical concepts. It isn't reasonable to expect people to avoid infringing something which is a core truth of the universe.
MIcrosoft is already running a bunch of stuff on Linux in the Azure cloud. They recognize they are a minority player in the cloud space and they have to leverage technology that was designed to scale to large core counts, something they didn't do much of in Redmond historically. I actually do foresee a Microsoft-spin of Linux. Oracle is actually worse than Microsoft in many ways (NIH syndrome), and they have their own Linux distro now. It's all server-side though, so don't expect a Microsoft Linux desktop, ever. New NoC hardware architectures may end up making the whole Linux vs NT thing moot anyway from a technology point of view.
GPL != Open Source. They would never release any part of Windows under GPL, ever. For an entertaining read, go over the licensing agreement for the new "open source" .NET core, and decide for yourself what is REALLY the cancer.
Private companies can still be bought out. It's just that they are not listed on public exchanges; they are controlled via private equity. Valve is rolling in cash most likely (they have low relative operating costs), which would make them a hard acquisition target, but it's not impossible. They are heavily concentrated in their Steam business, which could be sunk at any time by a wrong turn in patent litigation, and I doubt they have a patent portfolio large enough to force a potential opponent to cross-license. The resulting damages awarded by such a suit would be astronomical if successful, and given how much money Valve has made in the past it is only a matter of time before lawyers start showing up claiming irreparable harm. One bright side is that they are getting into the console business, which means hardware vendors would likely come to their aid in a suit of that kind (mutually assured destruction). My point is that there are no guarantees, and most software licenses are barely deserving of the name anyway. I don't spend money on any product on Steam I am not okay with losing tomorrow, and neither should anyone else.
The spying apparatus isn't out of control. Its out of your control.
There is no reason why people should be making $30 a copy for compression software that does the same thing today that it did 20 years ago. There is a point where boxed licensing ceases to be about paying programmers and instead becomes rents taking. For software that is not widely used but is otherwise essential to a particular businesses competitive advantage I might agree. For software that is very mature, widely relied upon, and a fundamental building block of infrastructure, I think free software has advantages that proprietary stuff does not, and by virtue of business need being spread over a large group of people, you are more likely to get constructive contribution. The success of the Linux kernel project, Apache, GNU build tools, Xen hypervisor, Docker, and several Java application servers is a testament to that. If you do not have users who are engineers (I.e., you are running on Windows), then yeah, expect the code to suck, if not be downright malicious.
You mean like an embedded/portable device, or a server that operates in an environment where you want to recover quickly from loss of power (such as when a server gets power-killed via a Smart PDU due to a transient hardware/software fault detected by an external monitor), or a server in an auto-scaling VM environment.
The Linux kernel is monolithic because that's what runs efficiently on current processors. Microkernels have some nice features regarding safety, but they are slow. Doing stuff like filesystem access in the userspace involves a context switch, which means you leave the CPU cache in many cases. Linus had a big discussion with Tanennbaum over that. Microkernels are good theory, and I think they are the future of reliable operating systems. However, current widely available CPU hardware is not DESIGNED to run microkernels in a way that is cache-local. Operating systems have to work with the reality the hardware provides. Mac OSX has a microkernel system, but Apple ended up having to move some userspace drivers into the microkernel for the same reason described above.
I disagree. Dependency management is hugely important for servers. That's the whole reason things like apt and rpm exist, to say nothing of orchestration and configuration management stuff like Puppet and Chef. The fact is servers are run by operators who usually wear many hats and don't have time to "muck around" with failed software upgrades because services didn't shut down/upgrade/restart in the correct order. That's all cool when you have 2 or 3 servers to manage. When you have 1000 servers and 100 of them are down it's a huge inconvenience to troubleshoot.
Actually, the reason "export strength" RSA even exists is because of U.S. law classifying long-key RSA the same as military hardware. In other words, you could be sent to prison for selling it outside the U.S. If the FBI/NSA had their way back in the 1990s, everyone would be using this weak kind of "security" today.
Rights were not granted by the Constitution. They were recognized. They pre-existed. People don't have those rights because they are Americans. They have those rights because they are human beings. If the government chooses not to recognize those rights then that is a choice, but it does not alter the fact that those rights exist. Otherwise, it would be impossible for a government to be guilty of rights violations.
How many warrant requests has FISA turned down, ever?
Yeah, they would not surveil Congress staff working for the Intelligence Oversight Committee, because you know, that's totally beyond the scope of what they do...
You want the impossible. You want communications you can trust without having to understand how they happen. The usual compromise is to the Other Guy TM take care of the security for you, whether that's a dumbed down interface or cloud hosted services. Everyone's already doing this: its called Google and Facebook. It turns out the Other Guy TM isn't always so great at protecting you in all situations. So now you're back to square one: how do I have secure comms without needing to understand what's happening?
ORM came around, which IMHO is a totally ass-backward way of dealing with a DB from an OO point-of-view.
That's because SQL is a really horrible language. If it was structured algebraically with real relational operators this sort of mapping would be trivial. Instead you must choose which vendor's butchering of the English language you would prefer to write your complex set logic operation in. I'm not even going to get into the query optimizer. Key-value stores I think are a stage of grieving over how screwed up relational DB's are today.
Also, clients demanded that we run stuff in J2EE containers and hence, that we write it in Java, which I still consider to have been a marketing exercise by Sun Microsystems to obtain more broad meaning for their ailing Spark CPU line (Java has always ran suspiciously better on *nix than any other platform). Little did they count on GNU/Linux taking over the server universe. We did go Java, but never liked it, and still consider it the result of brainwashing, and don't understand the need for all those extra layers. There is not one thing that the container does that the OS cannot do better, except packaging, and ever there, J2EE is "write once, debug everywhere" in the field and therefore of little real help.
Well, simply put, Java eats memory for breakfast, lunch, and dinner. It's not as bad as it used to be, but Java inherently uses more memory than some other "managed code" languages because of how heavily it relies on heap storage, which has to be GC'ed. When you have many Java applications running on the same box, it is useful to share heap storage so that you don't have a situation where a Java application dies due to inability to allocate heap when 30% of available RAM is allocated but not in use by other Java processes. Containers also do things like connection pooling (because database connections are slow to set up and the OS doesn't do that), thread pooling (because the OS takes a long time to spin up a thread compared to execution time for very short function calls), message dispatch (because FIFO's don't always do the job on a heavily loaded system), and supervision (because sysv init sucks and OS people tend to oppose more complete supervisors). Was J2EE too big? Yeah, but the business need was still there.
I don't believe in making development easier:
I don't either. A bunch of peasant rabble; the lot of them.
So you see, for me, the current situation with the traction of NoSQL and the immense opportunily (and necessity, IMHO) to make the server-side efficient and lean again (power is now a major cost in the data center, vs bandwidth) is really a lot of "back to the future".
The current situation with the traction of NoSQL has to do with the fact that there are limits to how you can scale an ACID-compliant relational database, particularly when the data store is distributed over a network. Most of NoSQL (I say most, not all) revolves around fancy key-value stores. Key-value stores (which do not enforce relational consistency) have the property that data can be distributed across multiple nodes and can be retrieved in sub-linear time via a hashing algorithm like CHORD. Web developers basically discovered that they didn't need all of the functions that SQL databases provided, and by relaxing a few ACID constraints they could scale out with commodity hardware. Relational database servers are actually pretty efficient given the constraints they operate under (with the exception of the query parser), but those constraints don't always make sense.
Dogs understand more than you think. They have been bred over a thousand years to better grasp human communication; they pay more attention than other canines to certain parts of the face, and pick up nonverbal cues that humans sometimes miss or ignore. They tend to be interested only in certain things, though, which some people mistake for lack of intelligence.
What's wrong with me? "I think you're crazy." I want a second opinion! "You're also lazy."