BSDs are actually attempting to copy the new Linux network code, since it's years ahead of the BSDs.
Hmm, that must be why Netflix and WhatsApp run FreeBSD (Netflix alone being responsible for over 30% of of US Internet traffic and able to saturate multiple 40GigE links from a single server with SSL) and why Facebook posted a job advert for a Linux kernel dev a few months ago with the goal of 'making the Linux network stack competitive with FreeBSD within 5 years'.
Last time I was in the Bay Area (last year), I saw an advert for MIPS in quite a few places. I've never seen one anywhere else in the world. It still screams 'tech', though it also screams 'crappy tech', so maybe that's not such a ringing endorsement...
That's fine, if the goal for the language is to whither. 10 years ago, I'd have recommended learning C and giving C++ a wide berth. I started new projects written in C. Now I'd recommend avoiding C for anything where there is another option. If a project is already written in C, I'd consider using C++ for new code and gradually migrating rest.
If the goal is to provide a good portable systems programming language then C is no longer succeeding.
For garbage collectors, I'll agree (as long as, by Java, you mean MMTk on Jikes RVM and not OpenJDK). For JITs... no. CoreCLR is a lot nicer. It supports nested JITs with fallback, so you can add a new JIT easily and have it bail to another one when it can't handle a particular construct. This makes incremental development and research prototypes that focus on a specific area both a lot easier than anything I've seen in a JVM. Modifying the Jikes RVM JIT is horrible (actually, the Jikes RVM code in general is fragile and flakey - MMTk isn't actually good, it's just that it doesn't really have any less-buggy competition).
Exactly what I was going to say. Java is good at cross-platform GUIs if your idea of a good cross-platform GUI is one that looks and feels the same on all platforms. A good GUI, however, is one that integrates with the host platform and matches all of the platform's human interface guidelines. Java GUIs don't do this. AWT aimed to, but it was deprecated in favour of Swing. Swing implements everything in Java, with pluggable looks and feels, but the looks and feels never quite match the platform. SWT thinly wraps the host windowing toolkit and works fine as long as your host system is win32, otherwise it has a bunch of impedance mismatches and ends up leaking CPU.
As others have pointed out, Twitter does engage in censorship, which might make it ineligible for safe harbour provisions (which require that you do not actively take a role in the content of the communication that you host).
They are a company that doesn't have as much experience in litigation. Yahoo!, Microsoft, and AOL have all been involved in enough lawsuits that they keep a warehouse full of lawyers to airdrop on anyone with a stupid-looking lawsuit. Twitter is big enough to have enough money to be a good target, but not experienced enough to necessarily be a particularly tough opposition on court.
iRex went out of business quite a while ago, as a result of not realising that power management was an important feature for an eBook reader. Probably not something Ireland wants to emulate.
The problem is that they don't bring many jobs and the ones that they do are low-skill, low-pay. For example, Apple runs a call centre and a distribution centre in Ireland. Callcentre employees are just reading through a script, the shipping centre is moving boxes around. They're not bringing the engineering and R&D jobs that come with high salaries that translate to higher income tax revenues and knock-on benefits in the local economies from increased spending.
Java isn't a bad language. It's a constrained language, but in general it's constrained in a good way. It may make it difficult to write the best solution, but it makes it impossible to write the ten worst solutions and easiest to write a not-too-bad solution to any given problem. It also strongly encourages modularity and provides tools for reducing privilege for parts of a program so that you don't need to trust all programmers in your address space equally. It's certainly not the best tool for all jobs, but if you have a complex business application that you want to support for a long time with relatively high programmer turnover, it's far from the worst tool.
That's a good reason for providing a C interface, but there's no reason not to use C++ (or Objective-C) inside your library. That said, if you provide a C++ interface that uses smart pointers and conveys explicit ownership semantics, then it's much easier to machine generate interfaces for other languages (even for C) that care about memory management.
The real problem with C is that WG14 sat on its fingers between 1999 and 2011. C11 gave us:
_Generic - Useful for a few things (mostly tgmath.h, which I've rarely seen used in real code because C's type promotion rules make it very dangerous, but it was quite embarrassing that, for 12 years, the C standard mandated a header that could not be implemented in standard C). Existing compilers have all provided a mechanism for doing the same thing (they had to, or they couldn't implement tgmath.h), but it was rarely used in real code. Oh, and the lack of type promotion in _Generic makes it annoyingly verbose: int won't be silently cast to const int, for example, so if you want to handle both then you need to provide int and const int cases, even though it's always safe to use const int where an int is given as the argument.
_Static_assert - useful, but most people had already implemented a similar macro along the lines of:
This gives a 1 or -1 element array, depending on whether x is true. If x is true, the array is optimised away, if x is false then you get a compile-time failure. _Static_assert in the compiler gives better error diagnostic, but doesn't actually increase the power of the language.
And then we get on to the big contributions: threads and atomics. The threading APIs were bogged down in politics. Microsoft wanted a thin wrapper over what win32 provided, everyone else a thin wrapper over what pthreads provided. Instead, we got an API based on a small company that no one had ever heard of's library, which contains a clusterfuck of bad design. For example, the timeouts assume that the real-time clock is monotonic. Other threading libraries fixed this in the '90s and provide timeouts expressed relative to a monotonic clock.
The atomics were lifted from a draft version of the C++11 spec (and, amusingly, meant that C11 had to issue errata for things that were fixed in the final version of C++11). They were also not very well thought through. For example, it's completely permitted in C11 to write _Atomic(struct foo) x, for any size of struct foo, but the performance characteristics will be wildly different depending on that size. It's also possible to write _Atomic(double) x, and any operation on x must save and restore the floating point environment (something that no compiler actually does, because hardly anyone fully implements the Fortran-envy parts of even C99).
In contrast, let's look at what WG21 gave us in the same time:
Lambdas. C with the blocks extension (from Apple, supported by clang on all platforms that clang supports now) actually gives us more powerful closures, and even that part of blocks that doesn't require a runtime library (purely downward funargs) would have been a useful addition to C. Closures are really just a little bit of syntactic sugar on a struct with a function pointer as a field, if you ignore the memory management issues (which C++ did, requiring you to use smart pointers if you want them to persist longer than the function in which they're created). C++14 made them even nicer, by allowing auto as a parameter type, so you can use a generic lambda called from within the function to replace small copied and pasted fragments.
Atomics, which were provided by the library and not the language in C++11. Efficient implementations use compiler builtins, but it's entirely possible to implement them with inline assembly (or out-of-line assembly) and they can be implemented entirely in terms of a one-bit lock primitive if required for microcontroller applications, all within the library. They scale down to small targets a lot better than the C versions (which require invasive changes to the compiler if you want to do anything different to conventional implementations).
Threads: Unlike the C11 mess, C++11 threads provide useful high-level abstractions. Threads that can be started fro
In terms of Linux, it's not classical security through obscurity, it's security through diversity. One of the reasons Slammer was so painful a decade ago was that most institutions had a Windows monoculture. The time between one machine being infected on your network and every machine on your network being infected was about 10 minutes (a fresh Windows install on the network was compromised before it finished running Windows Update for the first time). If you'd had a network that was 50% Windows and 50% something else, then it would only have infected half of your infrastructure and you'd have been able to pull the plug on the Windows machines and start recovery. It's possible to write cross-platform malware, but it's a lot harder (though there's some fun stuff out of one of the recent DARPA programs writing exploit code that is valid x86 and ARM code, relying on encodings that are nops in one and valid in the other, interspersed with the converse). Writing malware that can attack half a dozen combinations of OS and application software is difficult.
This is why Verisign's root DNS runs 50% Linux, 50% FreeBSD and of those they run two or three userland DNS servers, so an attack on a particular OS or particular DNS server will only take out (at most) half of the machines. Even an attack on an OS combined with an independent attack on the DNS server will still leave them with about a quarter functional, which will result in a bit more latency for Internet users, but leave them functioning.
You got lucky. There are two problems with most Antivirus software:
Most of them still use system call interposition. They're vulnerable to a whole raft of time-of-check to time-of-use errors, so the only part that actually catches things is the binary signature checking, and that requires you to install updates more frequently than malware authors release new versions - it's a losing battle.
They run some quite buggy code in high privilege. In the last year, all of the major AV vendors have had security vulnerabilities. My favourite one was Norton, which had a buffer overflow in their kernel-mode scanner. Providing crafted data to it allowed an attacker to get kernel privilege (higher than administrator privilege on Windows). You could send someone an email containing an image attachment and compromise their system as long as their mail client downloaded the image, even if they didn't open it. It's hard to argue that software that allows that makes your computer more secure.
Direct government control isn't required. The good capitalist solution is not that different to the socialist solution: make homeowners own the last mile (fibre from your house to the cabinet is yours, though you may jointly own some shared trunking with your neighbours). The connections from the cabinets should be owned by public interest companies, with the shares owned by the homeowners. Providing Internet connectivity to the network would be something that you'd open to tender by any companies (for-profit or non-profit) that wanted to provide it.
The situation in most of the USA is that it's been done using the worst possible mixture of laissez-fair capitalism and central planning. Vast amounts of taxpayer money have been poured into the infrastructure, yet that infrastructure is owned by a few companies and they have geographical monopolies and are now owned by their customers, so have no incentive to improve it. Oh, and regulator capture means that it's actually illegal to fix the problem in a lot of places. You can provide an incentive in several ways:
Tax penalties or fines for companies that don't improve their infrastructure. Big government hammer, and very difficult to enforce usefully.
Try to align the ownership of the companies with their customers. Companies have to do what their shareholders want and if their shareholders want them to upgrade the network because they're getting crap service then they will.
Ensure that there's real competition. This is difficult because it's hard to provide any useful differentiation between providers of a big dumb pipe and the cost for new entrants into the market is very high.
Android and iOS have very different philosophies. Android devices aim to be general-purpose computer, iOS devices aim to be extensions to a general-purpose computer. I have an Android tablet and an iPad, and I find I get a lot more use from the iPad because it doesn't try to replace my computer. There's a bunch of stuff that I can do on the Android tablet that I can't do on the iPad, but all of it is stuff that I'd be better off doing on my laptop anyway (with the one exception of an IRC client that doesn't disconnect when I switch to a different window). I still use Android for my phone, because OSMAnd~ (offline maps, offline routing, open source, and good map data) is the killer app for a smartphone for me and the iOS port is far less good.
Alas, it's a shame that it doesn't mean anything. The point here is that the Earth has undergone many shifts in its climate, sometimes in a startlingly short period of time
Except that the difference in temperature between the peak of the Medieval Warm Period and the bottom of the Little Ice Age were significantly smaller than the difference between the current temperature and the bottom of the Little Ice Age. The last time we saw an increase in temperature equivalent to the last 200 years it was over a period of tens of thousands of years.
Go and read a news story about an area of science that you know about and compare it to what the original research actually claimed. Now realise that press reports about climate change are no more accurate than that and go and read some of the papers. The models have been consistently refined for the last century, but the predictions are refinements (typically about specific local conditions and timescales), not complete reversals. Each year, there are more measurements that provide more evidence to support the core parts of the models.
Oh, and I don't think the words objectivist or dualistic mean what you think they mean. You can't discard evidence simply by throwing random words into a discussion.
Considering that the entire selling point behind Signal is that it's supposed to be resistant to "an adversary like the NSA," I would think their ability to trivially associate a key with a real person would kind of turn that on its head.
Any global passive adversary can do traffic analysis on any communication network. Signal's message encryption should stand up against the NSA unless there are any vulnerabilities in the implementation that the NSA has found and not told anyone about or unless they have some magical decryption power that we don't know about (unlikely). Protection of metadata is much harder. If you connect to the Signal server and they can watch your network traffic and that of other Signal users, then they can infer who you are talking to. If they can send men with lawyers, guns, or money around to OWS then they can coerce them into recording when your client connects and from what IP, even without this.
In contrast, Tox uses a DHT, which makes some kinds of interception easier and others harder. There's no central repository mapping between Tox IDs and other identifiable information, but when you push anything to the DHT that's signed with your public key then it identifies your endpoint so a global passive adversary can use this to track you (Tox over Tor, in theory, protects you against this, but in practice there are so few people doing this that it's probably trivial to track).
No system is completely secure, but my personal thread model doesn't include the NSA taking an active interest in me - if they did that then there are probably a few hundred bugs in the operating systems and other programs that I use that they could exploit to compromise the endpoint, without bothering to attack the protocol. I'd like to be relatively secure against bulk data collection though - I don't want any intelligence or law enforcement agency to be able intercept communications unless at least one participant is actively under suspicion, because if you allow that you end up with something like Hoover's FBI or the Stazi..
Currently, lorry drivers have to take statutory breaks. In the EU, they can only drive for 4.5 hours before having to take a 45-minute break. They can also only drive 9 hours per day. If you have a self-driving lorry that's only good enough for motorways (predictable traffic, well-marked lanes) and the driver can be out of the driving seat resting (even sleeping) then the vehicle can drive itself for 20 hours a day and the driver can be a passenger except when it approaches built-up areas. That would dramatically reduce the number of drivers that you'd need for a haulage fleet.
Signal is probably secure, but all communication goes via OpenWhisperSystems' servers, as does registration (which ties your identity to your account). They can't be forced to MITM your connections (probably - unless someone finds a vulnerability in the protocol), but they can unilaterally delete your account and they can be coerced into doing so. In contrast, Tox is completely decentralised (no central servers, it's a pure peer-to-peer network). Your identity is just a public key, so the only people who can identify you on the network are people that you have told your public key to through some out-of-band mechanism (or people who can view enough of the network that they can associate a public key with something else - i.e. an adversary like the NSA).
It's why we had a change in language from global warming to climate change
We had the change from global warming to climate change because idiots kept ignoring the 'global' part and saying things like 'this summer is rubbish, so much for global warming!'. The weather is a complex chaotic system. Global warming means that the total amount of energy in this system is increasing. This is very simple to understand - more energy is arriving from the Sun than is being radiated into space, by quite a large amount. This is trivially measurable by pointing an infrared camera at the night side of the Earth from space (which NASA does).
The effects of this are more difficult to communicate, because they're not the same everywhere. Adding more energy to the air and water in the middle of the Atlantic, for example, is likely to cause more hurricanes to form, but it may also disrupt the gulf stream and lead to significantly colder weather for a lot of places.
In the 1600s the Thames used to freeze over so that you could safely walk from one side to the other
You mean right at the height of the Little Ice Age?
If that were to happen now climate 'scientists' would be up in arms.
If it were to happen now, then it would not be part of a prolonged cooling trend that had been going on for around 200 years at that point and was just reaching its peak, before starting to warm again. The global temperature then passed the peak of the previous warm period (the Medieval Warm Period) in the last century and kept climbing. But you knew all of that, right?
Yes, probably a lot of people. Before it was purchased, WhatsApp had a very strong privacy guarantee and made a marketing point of the fact that their protocol's end-to-end encryption meant that they couldn't spy on you even if they wanted to. When Facebook bought them, they announced that there would be no changes to this guarantee.
Not sure if it still is, but WhatsApp used to be free for the first year and then $1/year thereafter. $1/year isn't much, but it should be more than enough to cover the costs of moving short plain-text messages to and from users.
It was always a stupid-sounding idea to use Whatsapp (I mean that as a totally independent fact, relative to whether or not Whatsapp was actually any good or not). From the very beginning, it was just someone's proprietary app that used an undocumented protocol. Nobody who is trying to do things right, is going to use anything like that.
Of the proprietary messengers, WhatsApp was the least bad. It was founded by people who grew up in the Soviet Union and left with an abiding hatred of surveillance, had a very strong privacy policy, and did end-to-end encryption. Also, using Erlang on FreeBSD, it had a lot of geek cred. Unfortunately, when Facebook bought it there wasn't much chance of it keeping the philosophy of the founders. On the plus side, they did donate $1m from the sale price to the FreeBSD Foundation.
I used to be a big advocate of XMPP, but it's largely been mismanaged into the ground by a lack of leadership in the standards body and a lack of decent reference implementations for the client side. Tox seems like the best bet at the moment for producing something that is both secure and open, yet with implementations that you can give to normal humans and get them connected.
Scientists don't come out with headlines, journalists do. If you're getting you opinion of what scientists are saying from the third-hand reports in the media, then you might consider that your opinions don't actually reflect reality that much.
Slashdot Mirror
BSDs are actually attempting to copy the new Linux network code, since it's years ahead of the BSDs.
Hmm, that must be why Netflix and WhatsApp run FreeBSD (Netflix alone being responsible for over 30% of of US Internet traffic and able to saturate multiple 40GigE links from a single server with SSL) and why Facebook posted a job advert for a Linux kernel dev a few months ago with the goal of 'making the Linux network stack competitive with FreeBSD within 5 years'.
Last time I was in the Bay Area (last year), I saw an advert for MIPS in quite a few places. I've never seen one anywhere else in the world. It still screams 'tech', though it also screams 'crappy tech', so maybe that's not such a ringing endorsement...
You know, if you're going to reply to a post, it might be a good idea to read it all of the way to the end.
That's fine, if the goal for the language is to whither. 10 years ago, I'd have recommended learning C and giving C++ a wide berth. I started new projects written in C. Now I'd recommend avoiding C for anything where there is another option. If a project is already written in C, I'd consider using C++ for new code and gradually migrating rest.
If the goal is to provide a good portable systems programming language then C is no longer succeeding.
For garbage collectors, I'll agree (as long as, by Java, you mean MMTk on Jikes RVM and not OpenJDK). For JITs... no. CoreCLR is a lot nicer. It supports nested JITs with fallback, so you can add a new JIT easily and have it bail to another one when it can't handle a particular construct. This makes incremental development and research prototypes that focus on a specific area both a lot easier than anything I've seen in a JVM. Modifying the Jikes RVM JIT is horrible (actually, the Jikes RVM code in general is fragile and flakey - MMTk isn't actually good, it's just that it doesn't really have any less-buggy competition).
Exactly what I was going to say. Java is good at cross-platform GUIs if your idea of a good cross-platform GUI is one that looks and feels the same on all platforms. A good GUI, however, is one that integrates with the host platform and matches all of the platform's human interface guidelines. Java GUIs don't do this. AWT aimed to, but it was deprecated in favour of Swing. Swing implements everything in Java, with pluggable looks and feels, but the looks and feels never quite match the platform. SWT thinly wraps the host windowing toolkit and works fine as long as your host system is win32, otherwise it has a bunch of impedance mismatches and ends up leaking CPU.
As others have pointed out, Twitter does engage in censorship, which might make it ineligible for safe harbour provisions (which require that you do not actively take a role in the content of the communication that you host).
They are a company that doesn't have as much experience in litigation. Yahoo!, Microsoft, and AOL have all been involved in enough lawsuits that they keep a warehouse full of lawyers to airdrop on anyone with a stupid-looking lawsuit. Twitter is big enough to have enough money to be a good target, but not experienced enough to necessarily be a particularly tough opposition on court.
iRex went out of business quite a while ago, as a result of not realising that power management was an important feature for an eBook reader. Probably not something Ireland wants to emulate.
The problem is that they don't bring many jobs and the ones that they do are low-skill, low-pay. For example, Apple runs a call centre and a distribution centre in Ireland. Callcentre employees are just reading through a script, the shipping centre is moving boxes around. They're not bringing the engineering and R&D jobs that come with high salaries that translate to higher income tax revenues and knock-on benefits in the local economies from increased spending.
Java isn't a bad language. It's a constrained language, but in general it's constrained in a good way. It may make it difficult to write the best solution, but it makes it impossible to write the ten worst solutions and easiest to write a not-too-bad solution to any given problem. It also strongly encourages modularity and provides tools for reducing privilege for parts of a program so that you don't need to trust all programmers in your address space equally. It's certainly not the best tool for all jobs, but if you have a complex business application that you want to support for a long time with relatively high programmer turnover, it's far from the worst tool.
That's a good reason for providing a C interface, but there's no reason not to use C++ (or Objective-C) inside your library. That said, if you provide a C++ interface that uses smart pointers and conveys explicit ownership semantics, then it's much easier to machine generate interfaces for other languages (even for C) that care about memory management.
_Generic - Useful for a few things (mostly tgmath.h, which I've rarely seen used in real code because C's type promotion rules make it very dangerous, but it was quite embarrassing that, for 12 years, the C standard mandated a header that could not be implemented in standard C). Existing compilers have all provided a mechanism for doing the same thing (they had to, or they couldn't implement tgmath.h), but it was rarely used in real code. Oh, and the lack of type promotion in _Generic makes it annoyingly verbose: int won't be silently cast to const int, for example, so if you want to handle both then you need to provide int and const int cases, even though it's always safe to use const int where an int is given as the argument.
_Static_assert - useful, but most people had already implemented a similar macro along the lines of:
This gives a 1 or -1 element array, depending on whether x is true. If x is true, the array is optimised away, if x is false then you get a compile-time failure. _Static_assert in the compiler gives better error diagnostic, but doesn't actually increase the power of the language.
And then we get on to the big contributions: threads and atomics. The threading APIs were bogged down in politics. Microsoft wanted a thin wrapper over what win32 provided, everyone else a thin wrapper over what pthreads provided. Instead, we got an API based on a small company that no one had ever heard of's library, which contains a clusterfuck of bad design. For example, the timeouts assume that the real-time clock is monotonic. Other threading libraries fixed this in the '90s and provide timeouts expressed relative to a monotonic clock.
The atomics were lifted from a draft version of the C++11 spec (and, amusingly, meant that C11 had to issue errata for things that were fixed in the final version of C++11). They were also not very well thought through. For example, it's completely permitted in C11 to write _Atomic(struct foo) x, for any size of struct foo, but the performance characteristics will be wildly different depending on that size. It's also possible to write _Atomic(double) x, and any operation on x must save and restore the floating point environment (something that no compiler actually does, because hardly anyone fully implements the Fortran-envy parts of even C99).
In contrast, let's look at what WG21 gave us in the same time:
Lambdas. C with the blocks extension (from Apple, supported by clang on all platforms that clang supports now) actually gives us more powerful closures, and even that part of blocks that doesn't require a runtime library (purely downward funargs) would have been a useful addition to C. Closures are really just a little bit of syntactic sugar on a struct with a function pointer as a field, if you ignore the memory management issues (which C++ did, requiring you to use smart pointers if you want them to persist longer than the function in which they're created). C++14 made them even nicer, by allowing auto as a parameter type, so you can use a generic lambda called from within the function to replace small copied and pasted fragments.
Atomics, which were provided by the library and not the language in C++11. Efficient implementations use compiler builtins, but it's entirely possible to implement them with inline assembly (or out-of-line assembly) and they can be implemented entirely in terms of a one-bit lock primitive if required for microcontroller applications, all within the library. They scale down to small targets a lot better than the C versions (which require invasive changes to the compiler if you want to do anything different to conventional implementations).
Threads: Unlike the C11 mess, C++11 threads provide useful high-level abstractions. Threads that can be started fro
In terms of Linux, it's not classical security through obscurity, it's security through diversity. One of the reasons Slammer was so painful a decade ago was that most institutions had a Windows monoculture. The time between one machine being infected on your network and every machine on your network being infected was about 10 minutes (a fresh Windows install on the network was compromised before it finished running Windows Update for the first time). If you'd had a network that was 50% Windows and 50% something else, then it would only have infected half of your infrastructure and you'd have been able to pull the plug on the Windows machines and start recovery. It's possible to write cross-platform malware, but it's a lot harder (though there's some fun stuff out of one of the recent DARPA programs writing exploit code that is valid x86 and ARM code, relying on encodings that are nops in one and valid in the other, interspersed with the converse). Writing malware that can attack half a dozen combinations of OS and application software is difficult.
This is why Verisign's root DNS runs 50% Linux, 50% FreeBSD and of those they run two or three userland DNS servers, so an attack on a particular OS or particular DNS server will only take out (at most) half of the machines. Even an attack on an OS combined with an independent attack on the DNS server will still leave them with about a quarter functional, which will result in a bit more latency for Internet users, but leave them functioning.
Most of them still use system call interposition. They're vulnerable to a whole raft of time-of-check to time-of-use errors, so the only part that actually catches things is the binary signature checking, and that requires you to install updates more frequently than malware authors release new versions - it's a losing battle.
They run some quite buggy code in high privilege. In the last year, all of the major AV vendors have had security vulnerabilities. My favourite one was Norton, which had a buffer overflow in their kernel-mode scanner. Providing crafted data to it allowed an attacker to get kernel privilege (higher than administrator privilege on Windows). You could send someone an email containing an image attachment and compromise their system as long as their mail client downloaded the image, even if they didn't open it. It's hard to argue that software that allows that makes your computer more secure.
The situation in most of the USA is that it's been done using the worst possible mixture of laissez-fair capitalism and central planning. Vast amounts of taxpayer money have been poured into the infrastructure, yet that infrastructure is owned by a few companies and they have geographical monopolies and are now owned by their customers, so have no incentive to improve it. Oh, and regulator capture means that it's actually illegal to fix the problem in a lot of places. You can provide an incentive in several ways:
Android and iOS have very different philosophies. Android devices aim to be general-purpose computer, iOS devices aim to be extensions to a general-purpose computer. I have an Android tablet and an iPad, and I find I get a lot more use from the iPad because it doesn't try to replace my computer. There's a bunch of stuff that I can do on the Android tablet that I can't do on the iPad, but all of it is stuff that I'd be better off doing on my laptop anyway (with the one exception of an IRC client that doesn't disconnect when I switch to a different window). I still use Android for my phone, because OSMAnd~ (offline maps, offline routing, open source, and good map data) is the killer app for a smartphone for me and the iOS port is far less good.
Alas, it's a shame that it doesn't mean anything. The point here is that the Earth has undergone many shifts in its climate, sometimes in a startlingly short period of time
Except that the difference in temperature between the peak of the Medieval Warm Period and the bottom of the Little Ice Age were significantly smaller than the difference between the current temperature and the bottom of the Little Ice Age. The last time we saw an increase in temperature equivalent to the last 200 years it was over a period of tens of thousands of years.
Go and read a news story about an area of science that you know about and compare it to what the original research actually claimed. Now realise that press reports about climate change are no more accurate than that and go and read some of the papers. The models have been consistently refined for the last century, but the predictions are refinements (typically about specific local conditions and timescales), not complete reversals. Each year, there are more measurements that provide more evidence to support the core parts of the models.
Oh, and I don't think the words objectivist or dualistic mean what you think they mean. You can't discard evidence simply by throwing random words into a discussion.
Considering that the entire selling point behind Signal is that it's supposed to be resistant to "an adversary like the NSA," I would think their ability to trivially associate a key with a real person would kind of turn that on its head.
Any global passive adversary can do traffic analysis on any communication network. Signal's message encryption should stand up against the NSA unless there are any vulnerabilities in the implementation that the NSA has found and not told anyone about or unless they have some magical decryption power that we don't know about (unlikely). Protection of metadata is much harder. If you connect to the Signal server and they can watch your network traffic and that of other Signal users, then they can infer who you are talking to. If they can send men with lawyers, guns, or money around to OWS then they can coerce them into recording when your client connects and from what IP, even without this.
In contrast, Tox uses a DHT, which makes some kinds of interception easier and others harder. There's no central repository mapping between Tox IDs and other identifiable information, but when you push anything to the DHT that's signed with your public key then it identifies your endpoint so a global passive adversary can use this to track you (Tox over Tor, in theory, protects you against this, but in practice there are so few people doing this that it's probably trivial to track).
No system is completely secure, but my personal thread model doesn't include the NSA taking an active interest in me - if they did that then there are probably a few hundred bugs in the operating systems and other programs that I use that they could exploit to compromise the endpoint, without bothering to attack the protocol. I'd like to be relatively secure against bulk data collection though - I don't want any intelligence or law enforcement agency to be able intercept communications unless at least one participant is actively under suspicion, because if you allow that you end up with something like Hoover's FBI or the Stazi..
Currently, lorry drivers have to take statutory breaks. In the EU, they can only drive for 4.5 hours before having to take a 45-minute break. They can also only drive 9 hours per day. If you have a self-driving lorry that's only good enough for motorways (predictable traffic, well-marked lanes) and the driver can be out of the driving seat resting (even sleeping) then the vehicle can drive itself for 20 hours a day and the driver can be a passenger except when it approaches built-up areas. That would dramatically reduce the number of drivers that you'd need for a haulage fleet.
Signal is probably secure, but all communication goes via OpenWhisperSystems' servers, as does registration (which ties your identity to your account). They can't be forced to MITM your connections (probably - unless someone finds a vulnerability in the protocol), but they can unilaterally delete your account and they can be coerced into doing so. In contrast, Tox is completely decentralised (no central servers, it's a pure peer-to-peer network). Your identity is just a public key, so the only people who can identify you on the network are people that you have told your public key to through some out-of-band mechanism (or people who can view enough of the network that they can associate a public key with something else - i.e. an adversary like the NSA).
It's why we had a change in language from global warming to climate change
We had the change from global warming to climate change because idiots kept ignoring the 'global' part and saying things like 'this summer is rubbish, so much for global warming!'. The weather is a complex chaotic system. Global warming means that the total amount of energy in this system is increasing. This is very simple to understand - more energy is arriving from the Sun than is being radiated into space, by quite a large amount. This is trivially measurable by pointing an infrared camera at the night side of the Earth from space (which NASA does).
The effects of this are more difficult to communicate, because they're not the same everywhere. Adding more energy to the air and water in the middle of the Atlantic, for example, is likely to cause more hurricanes to form, but it may also disrupt the gulf stream and lead to significantly colder weather for a lot of places.
In the 1600s the Thames used to freeze over so that you could safely walk from one side to the other
You mean right at the height of the Little Ice Age?
If that were to happen now climate 'scientists' would be up in arms.
If it were to happen now, then it would not be part of a prolonged cooling trend that had been going on for around 200 years at that point and was just reaching its peak, before starting to warm again. The global temperature then passed the peak of the previous warm period (the Medieval Warm Period) in the last century and kept climbing. But you knew all of that, right?
Yes, probably a lot of people. Before it was purchased, WhatsApp had a very strong privacy guarantee and made a marketing point of the fact that their protocol's end-to-end encryption meant that they couldn't spy on you even if they wanted to. When Facebook bought them, they announced that there would be no changes to this guarantee.
Not sure if it still is, but WhatsApp used to be free for the first year and then $1/year thereafter. $1/year isn't much, but it should be more than enough to cover the costs of moving short plain-text messages to and from users.
It was always a stupid-sounding idea to use Whatsapp (I mean that as a totally independent fact, relative to whether or not Whatsapp was actually any good or not). From the very beginning, it was just someone's proprietary app that used an undocumented protocol. Nobody who is trying to do things right, is going to use anything like that.
Of the proprietary messengers, WhatsApp was the least bad. It was founded by people who grew up in the Soviet Union and left with an abiding hatred of surveillance, had a very strong privacy policy, and did end-to-end encryption. Also, using Erlang on FreeBSD, it had a lot of geek cred. Unfortunately, when Facebook bought it there wasn't much chance of it keeping the philosophy of the founders. On the plus side, they did donate $1m from the sale price to the FreeBSD Foundation.
I used to be a big advocate of XMPP, but it's largely been mismanaged into the ground by a lack of leadership in the standards body and a lack of decent reference implementations for the client side. Tox seems like the best bet at the moment for producing something that is both secure and open, yet with implementations that you can give to normal humans and get them connected.
Scientists don't come out with headlines, journalists do. If you're getting you opinion of what scientists are saying from the third-hand reports in the media, then you might consider that your opinions don't actually reflect reality that much.