My view is the problem is developers insisting on using the newest features of everything for no particular reason that they are new.
A bunch of the stuff I work with moved quite aggressively to C++11 and then C++14 when the compiler and standard library support became available. This switch improved memory safety and improved performance. Those both seem like pretty good reasons. This is pretty common for libraries: new features are added because they make life for consumers better either by making things faster, more secure, less code, or some combination of the above.
Red Hat is pretty good at doing security back ports for popular things, but if upstream has EOL'd the version that ships with a particular RHEL release and someone finds a vulnerability then you may not get an update with RHEL. You're then stuck compiling a bunch of stuff from source, using a third-party repo (which may cause interesting conflicts), or switching to a different distro / OS.
SystemD is created by Lennart Poettering, who is employed as a software developer at RedHat and was for all of the time that he worked on SystemD. In what way does this mean to you that 'Red Hat did not create systemd'?
That's only half of the solution. The other fix you need is: don't visit malicious web sites. A password manager plugin should be split into one part that maintains the DB and one part that runs in the context of each tab and has access to only the passwords that that tab requires. With the old Firefox extension model, there is no way of doing that (all tabs run in the same context) and so a compromise of one tab will compromise all secret information owned by the extension. There's no way to fix this without a complete redesign.
The UI is the least of their problems, the big issue is the security architecture. If I compromise a tab that's displaying Slashdot, I should be able to get access to the password for Slashdot (maybe), but definitely not for any other site. With Firefox, the password manager runs in the same address space as all of the tabs and has all of your passwords in memory. A single libpng or libjpg arbitrary code execution vulnerability and a malicious image can expose all of your passwords to an attacker. A single libavcodec or libavformat arbitrary code execution vulnerability and a malicious video or audio file can expose all of your passwords to an attacker. Go and look at the CVE lists for these projects and decide whether you'd trust Firefox with a password...
It's often problematic when you get work that's slightly outside the scope of competence for the publication. This is particularly common for security-related things. Most of the top conferences and journals have at least one person that they can ping to get a sensible opinion about security-related things. I often get security papers to review for a couple of computer architecture venues, because the set of people that know enough to have plausibly sensible opinions about things that overlap both is pretty small (and gets much smaller when you throw in compilers, which can be difficult when you need to find a non-conflicted reviewer). The Dunning-Kruger Effect is just as common in academia, so you'll often see reviews from someone with no security background on such a paper marking their confidence in their review as 'high' and be able to spot 5 easy attacks that completely by the time you get to page 2. My general view when I review these is that my knowledge of security is fairly small, and if I can tell your system is stupid then it's really stupid. Fortunately, I work with enough people that actually know about security that I can generally get a good answer about whether a security claim is at least broadly plausible.
True. A good workman, in contrast, picks the correct tool as the first step in working on any job and sidesteps a lot od the problems that a bad workman faces.
Here's a first step: Stop referring to advertising platforms[1] as 'social media'. This is probably the most impressive advertising success in recent decades. A set of companies have managed to get a positive-sounding term attached to their product to such an extent that all mainstream media use it. It's as if tobacco companies had managed to get 'happiness products' used as the generic term for all of their wares.
[1] I'm being generous here: psychological manipulation platforms might be a better term: their sole reason for existing is to build a detailed psychological profile that can be used to manipulate you. The most benign use of this is to try to influence you to favour a particular brand over another.
To generate accurate credit information, you need as many sources of information as possible. The more accurate you are, the more people are willing to share data with you and the more that will pay you to perform credit checks. The real issue is not that there are so few (the natural number of such agencies is one), it's that their procedures are opaque and most banks (and increasingly many other organisations) rely on them completely without performing basic sanity checking themselves.
It's worth noting that this was published in Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies. This is a brand-new journal, so all submissions are likely to be either bad work that can't get published anywhere else, from people who are submitting some of their second-rate work to help the journal get established, or from people who are betting that it will become well-known later and so submit something there in the hope that they'll retroactively end up with a prestigious publication. The total citation count for the entire journal is 5, currently.
More importantly, it's a paper about a security technique that wasn't sent to a security venue. IEEE Security and Privacy now does a rolling submission and EuroS&P has just sent out the first round of reviews. Anyone with a really good security idea will have sent it to one of these venues. There are then a bunch of second-tier (but still respected) conferences where you'll get good reviews. This paper was carefully sent to a venue that was unlikely to have any reviewers with a background in security.
None of this necessarily means that it's bad work: sometimes you get really good people at institutions that have no background in a particular field submitting work to the wrong kind of venue because they don't know any better. Unfortunately, this doesn't appear to be one of these cases.
There's no good way of doing this. Either the app compares them, in which case it's basically a U2F token where instead of pressing a button (optionally a fingerprint reader) you take a photo, which is a step backwards in usability, or the server compares them, in which case anyone who takes a photo of the object can now log in remotely without access to the thing.
Or if someone compromises an app on your phone with camera permission (or simply persuades you that this free game that you want to play needs camera permission) and takes a photo, they can then use the same photo.
I'm too lazy to RTFA, but the description in TFS is a bit confusing: are the photos really compared on the phone? If so, how do they communicate with the server, do they just speak the U2F protocol? If so, they've just replaced a button with the need to take a photo, which doesn't sound like much of a UI improvement. If they're comparing the photos on the server, then simply copying the photo makes it trivial to launch remote attacks.
C11 has the same set of atomics as C++11. Even the syntax is almost the same: std::atomic<T> vs _Atomic(T).
The problem with C++ in embedded contexts is that the C++ committee is explicitly opposed to subsetting, yet what you actually want is a subset. You typically don't want exceptions or RTTI, and you don't want locales or a bunch of other stuff from the standard library. You end up not writing C++, but writing some arbitrary subset of C++ and hoping that your compiler / standard library will keep supporting it.
To counter your anecdote: the SDK for ARM's mBed system is C++ and so is their newer mBed microkernel. Both run on systems with 32KB of RAM. I've written a thing to control the Christmas lights outside of my office that runs on an ARM Cortex M0 and uses C++ templates and some virtual functions to describe a stackable set of transforms that are applied to an LED strip. It uses about 1.8KB of RAM, because I didn't bother optimising it, but I could easily get it lower if I cared (the board has 32KB of RAM). For embedded programming, you probably don't want RTTI or exceptions, but that doesn't mean that you can't benefit from some memory safety.
It's perhaps worth noting that a number of 'regex' libraries aren't actually regular expressions, they are often provide some state that makes them equivalent to push-down automata, and therefore are able to parse all context-free languages. That doesn't necessarily make them the right tool for the job, of course.
The performance difference between C and a modern safer language is well under a factor of two. The performance difference between C and C++ using bounds-checked types and smart pointers everywhere is a few tens of percent. Unless you're targeting a system with 32KB of RAM or less, or you have very strict realtime guarantees (and so aren't even using malloc) there's rarely a good reason to use C these days.
Depend on the amount of code from the framework you actually need. If you're bringing in half a million lines of code to do something that could be done in a couple of thousand, then you're probably better off rolling your own: it's going to have far more tightly coupled logic and be more amenable to static analysis, as well as being an easier target to fuzz test.
If, on the other hand, you end up implementing most of the logic in a dependency, then you're probably better off using the one that's widely deployed. Even then it's not so clear cut, because it depends a bit on your threat model. There will likely be more vulnerabilities in your code, but (for most deployments) there will be more attackers for the generic code because other higher-value targets will be using the same framework and someone who finds a vulnerability in it will be doing so with the aim of attacking one of them - but that doesn't help you when the script kiddie that buys their exploit decides to attack you though. You're trading increased vulnerability to generic attacks for increased vulnerability for targeted attacks.
The average car lasts 11 years in the US, the average coal plant is something on the order of 45 years.
That's an interesting number. What happens to most of the 12-year-old cars? Are they scrapped, or sold overseas (ignoring the blip caused by cash for clunkers)? Is that a average a mean, mode, or median, and do you know what the distribution is (I don't doubt your numbers, I just wonder how many outliers there are - whether rich people are buying new cars every 2 years, poor people are keeping theirs for 20-30, or if this is a normal distribution)?
Post-doc student? Not sure what you mean by that - postdocs aren't students. £120K seems in the right ballpark for a PhD student for the entire degree, but near the top of the pay scale £120K/year doesn't sound too far off for the cost of a postdoc for one year including things like pension contributions and overheads.
Katrina caused less property damage than the hurricane a couple of years later. The big problem with Katrina was that it caused a collapse of a chunk of the insurance industry. Several (six, I think) insurance companies went out of business because they had incorrectly modelled systematic risk: they thought they had a diversified portfolio of risk, but didn't take into account that several of the things that they'd insured against either caused each other or had the same cause. The insurance industry (well, the surviving bits) spent a lot in the following years on improving their models of systemic risk (some of my colleagues worked with them on identifying cybersecurity risks).
This was compounded in the case of Katrina by the fact that a lot of the affected people were too poor to afford Federal flood insurance the combination of the uninsured and the insured-but-by-a-company-that's-gone-bust a huge number of people (and companies) didn't have the financial ability to rebuild. This was exacerbated by a poor response from both the local and Federal governments.
TL;DR: Katrina was a bad storm, but it wasn't the size of the storm that made it such a big news story for so long.
That varies a bit. One of my friends was a biology postdoc, but quit academia to move to a big pharma company. Her starting salary was about 50% higher than she had been making and she had the funds to recruit a small team to work for her. She's definitely still using her biology PhD, but she's no longer in the academic track (though she is still publishing, so could return without much difficulty if she wants to).
Sounds a bit low, but about right. From a UK perspective:
Each faculty member is typically supervising 2-12 PhD students, let's say an average of 4 to be conservative. It takes 3-4 years to complete a PhD, so that works out at one PhD per year. A faculty position is typically 20-30 years, so that's an average of about 25 PhDs produces per faculty member. Assuming a static faculty size, only 1/25, or 4% will get faculty jobs. Most good science faculties are growing, but only by a few percent a year, so I'd expect around 5-6% of PhD students to end up with faculty positions.
That's not necessarily a bad thing: when I went back to academia, I turned down a job at Google that paid a lot more to do it, and if it stops being fun here then I'd be very quick to head back to industry (or industrial research). It definitely improves a working environment when everyone there knows that if they quit they could be making at least double their current salary within a week.
If you look at the figures for some the the eastern European nations, the EV is about the same as the reference ICE figures.
The usual argument for EVs is that it's easier to replace a few power stations with something less polluting than it is to replace every car. It's also likely easier to do carbon sequestration and to filter particulates from a large industrial installation than from a few million tiny portable generators.
Examples: Ancient Greece / Macedonia, Roman Empire, Vikings. Lots of examples of highly successful civilisations that had high instances of homosexuality (Alexander the Great's wife complained that he'd rather sleep with his generals than with her) and seem to have done very well out of it.
Add to that, a lot of the most active ZFS developers work on the various OpenSolaris forks. A GPL'd version is completely useless to them. It's also not clear if Oracle even could release a GPL'd version. If they've taken any code from OpenZFS, then their version will include CDDL'd code that they don't own the copyright to, which would make relicensing impossible without replacing all of that code.
Slashdot Mirror
My view is the problem is developers insisting on using the newest features of everything for no particular reason that they are new.
A bunch of the stuff I work with moved quite aggressively to C++11 and then C++14 when the compiler and standard library support became available. This switch improved memory safety and improved performance. Those both seem like pretty good reasons. This is pretty common for libraries: new features are added because they make life for consumers better either by making things faster, more secure, less code, or some combination of the above.
Red Hat is pretty good at doing security back ports for popular things, but if upstream has EOL'd the version that ships with a particular RHEL release and someone finds a vulnerability then you may not get an update with RHEL. You're then stuck compiling a bunch of stuff from source, using a third-party repo (which may cause interesting conflicts), or switching to a different distro / OS.
SystemD is created by Lennart Poettering, who is employed as a software developer at RedHat and was for all of the time that he worked on SystemD. In what way does this mean to you that 'Red Hat did not create systemd'?
That's only half of the solution. The other fix you need is: don't visit malicious web sites. A password manager plugin should be split into one part that maintains the DB and one part that runs in the context of each tab and has access to only the passwords that that tab requires. With the old Firefox extension model, there is no way of doing that (all tabs run in the same context) and so a compromise of one tab will compromise all secret information owned by the extension. There's no way to fix this without a complete redesign.
The UI is the least of their problems, the big issue is the security architecture. If I compromise a tab that's displaying Slashdot, I should be able to get access to the password for Slashdot (maybe), but definitely not for any other site. With Firefox, the password manager runs in the same address space as all of the tabs and has all of your passwords in memory. A single libpng or libjpg arbitrary code execution vulnerability and a malicious image can expose all of your passwords to an attacker. A single libavcodec or libavformat arbitrary code execution vulnerability and a malicious video or audio file can expose all of your passwords to an attacker. Go and look at the CVE lists for these projects and decide whether you'd trust Firefox with a password...
It's often problematic when you get work that's slightly outside the scope of competence for the publication. This is particularly common for security-related things. Most of the top conferences and journals have at least one person that they can ping to get a sensible opinion about security-related things. I often get security papers to review for a couple of computer architecture venues, because the set of people that know enough to have plausibly sensible opinions about things that overlap both is pretty small (and gets much smaller when you throw in compilers, which can be difficult when you need to find a non-conflicted reviewer). The Dunning-Kruger Effect is just as common in academia, so you'll often see reviews from someone with no security background on such a paper marking their confidence in their review as 'high' and be able to spot 5 easy attacks that completely by the time you get to page 2. My general view when I review these is that my knowledge of security is fairly small, and if I can tell your system is stupid then it's really stupid. Fortunately, I work with enough people that actually know about security that I can generally get a good answer about whether a security claim is at least broadly plausible.
A BAD WORKMAN ALWAYS BLAMES HIS TOOLS
True. A good workman, in contrast, picks the correct tool as the first step in working on any job and sidesteps a lot od the problems that a bad workman faces.
[1] I'm being generous here: psychological manipulation platforms might be a better term: their sole reason for existing is to build a detailed psychological profile that can be used to manipulate you. The most benign use of this is to try to influence you to favour a particular brand over another.
To generate accurate credit information, you need as many sources of information as possible. The more accurate you are, the more people are willing to share data with you and the more that will pay you to perform credit checks. The real issue is not that there are so few (the natural number of such agencies is one), it's that their procedures are opaque and most banks (and increasingly many other organisations) rely on them completely without performing basic sanity checking themselves.
It's worth noting that this was published in Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies. This is a brand-new journal, so all submissions are likely to be either bad work that can't get published anywhere else, from people who are submitting some of their second-rate work to help the journal get established, or from people who are betting that it will become well-known later and so submit something there in the hope that they'll retroactively end up with a prestigious publication. The total citation count for the entire journal is 5, currently.
More importantly, it's a paper about a security technique that wasn't sent to a security venue. IEEE Security and Privacy now does a rolling submission and EuroS&P has just sent out the first round of reviews. Anyone with a really good security idea will have sent it to one of these venues. There are then a bunch of second-tier (but still respected) conferences where you'll get good reviews. This paper was carefully sent to a venue that was unlikely to have any reviewers with a background in security.
None of this necessarily means that it's bad work: sometimes you get really good people at institutions that have no background in a particular field submitting work to the wrong kind of venue because they don't know any better. Unfortunately, this doesn't appear to be one of these cases.
There's no good way of doing this. Either the app compares them, in which case it's basically a U2F token where instead of pressing a button (optionally a fingerprint reader) you take a photo, which is a step backwards in usability, or the server compares them, in which case anyone who takes a photo of the object can now log in remotely without access to the thing.
Or if someone compromises an app on your phone with camera permission (or simply persuades you that this free game that you want to play needs camera permission) and takes a photo, they can then use the same photo.
I'm too lazy to RTFA, but the description in TFS is a bit confusing: are the photos really compared on the phone? If so, how do they communicate with the server, do they just speak the U2F protocol? If so, they've just replaced a button with the need to take a photo, which doesn't sound like much of a UI improvement. If they're comparing the photos on the server, then simply copying the photo makes it trivial to launch remote attacks.
C++ has much more convenient atomics and such
C11 has the same set of atomics as C++11. Even the syntax is almost the same: std::atomic<T> vs _Atomic(T).
The problem with C++ in embedded contexts is that the C++ committee is explicitly opposed to subsetting, yet what you actually want is a subset. You typically don't want exceptions or RTTI, and you don't want locales or a bunch of other stuff from the standard library. You end up not writing C++, but writing some arbitrary subset of C++ and hoping that your compiler / standard library will keep supporting it.
To counter your anecdote: the SDK for ARM's mBed system is C++ and so is their newer mBed microkernel. Both run on systems with 32KB of RAM. I've written a thing to control the Christmas lights outside of my office that runs on an ARM Cortex M0 and uses C++ templates and some virtual functions to describe a stackable set of transforms that are applied to an LED strip. It uses about 1.8KB of RAM, because I didn't bother optimising it, but I could easily get it lower if I cared (the board has 32KB of RAM). For embedded programming, you probably don't want RTTI or exceptions, but that doesn't mean that you can't benefit from some memory safety.
This deserves to be moderated up, perhaps with the corollary that often they will suffer economic loss as a result of taking the time to do it right.
It's perhaps worth noting that a number of 'regex' libraries aren't actually regular expressions, they are often provide some state that makes them equivalent to push-down automata, and therefore are able to parse all context-free languages. That doesn't necessarily make them the right tool for the job, of course.
The performance difference between C and a modern safer language is well under a factor of two. The performance difference between C and C++ using bounds-checked types and smart pointers everywhere is a few tens of percent. Unless you're targeting a system with 32KB of RAM or less, or you have very strict realtime guarantees (and so aren't even using malloc) there's rarely a good reason to use C these days.
Depend on the amount of code from the framework you actually need. If you're bringing in half a million lines of code to do something that could be done in a couple of thousand, then you're probably better off rolling your own: it's going to have far more tightly coupled logic and be more amenable to static analysis, as well as being an easier target to fuzz test.
If, on the other hand, you end up implementing most of the logic in a dependency, then you're probably better off using the one that's widely deployed. Even then it's not so clear cut, because it depends a bit on your threat model. There will likely be more vulnerabilities in your code, but (for most deployments) there will be more attackers for the generic code because other higher-value targets will be using the same framework and someone who finds a vulnerability in it will be doing so with the aim of attacking one of them - but that doesn't help you when the script kiddie that buys their exploit decides to attack you though. You're trading increased vulnerability to generic attacks for increased vulnerability for targeted attacks.
The average car lasts 11 years in the US, the average coal plant is something on the order of 45 years.
That's an interesting number. What happens to most of the 12-year-old cars? Are they scrapped, or sold overseas (ignoring the blip caused by cash for clunkers)? Is that a average a mean, mode, or median, and do you know what the distribution is (I don't doubt your numbers, I just wonder how many outliers there are - whether rich people are buying new cars every 2 years, poor people are keeping theirs for 20-30, or if this is a normal distribution)?
Post-doc student? Not sure what you mean by that - postdocs aren't students. £120K seems in the right ballpark for a PhD student for the entire degree, but near the top of the pay scale £120K/year doesn't sound too far off for the cost of a postdoc for one year including things like pension contributions and overheads.
Katrina caused less property damage than the hurricane a couple of years later. The big problem with Katrina was that it caused a collapse of a chunk of the insurance industry. Several (six, I think) insurance companies went out of business because they had incorrectly modelled systematic risk: they thought they had a diversified portfolio of risk, but didn't take into account that several of the things that they'd insured against either caused each other or had the same cause. The insurance industry (well, the surviving bits) spent a lot in the following years on improving their models of systemic risk (some of my colleagues worked with them on identifying cybersecurity risks).
This was compounded in the case of Katrina by the fact that a lot of the affected people were too poor to afford Federal flood insurance the combination of the uninsured and the insured-but-by-a-company-that's-gone-bust a huge number of people (and companies) didn't have the financial ability to rebuild. This was exacerbated by a poor response from both the local and Federal governments.
TL;DR: Katrina was a bad storm, but it wasn't the size of the storm that made it such a big news story for so long.
That varies a bit. One of my friends was a biology postdoc, but quit academia to move to a big pharma company. Her starting salary was about 50% higher than she had been making and she had the funds to recruit a small team to work for her. She's definitely still using her biology PhD, but she's no longer in the academic track (though she is still publishing, so could return without much difficulty if she wants to).
Each faculty member is typically supervising 2-12 PhD students, let's say an average of 4 to be conservative. It takes 3-4 years to complete a PhD, so that works out at one PhD per year. A faculty position is typically 20-30 years, so that's an average of about 25 PhDs produces per faculty member. Assuming a static faculty size, only 1/25, or 4% will get faculty jobs. Most good science faculties are growing, but only by a few percent a year, so I'd expect around 5-6% of PhD students to end up with faculty positions.
That's not necessarily a bad thing: when I went back to academia, I turned down a job at Google that paid a lot more to do it, and if it stops being fun here then I'd be very quick to head back to industry (or industrial research). It definitely improves a working environment when everyone there knows that if they quit they could be making at least double their current salary within a week.
If you look at the figures for some the the eastern European nations, the EV is about the same as the reference ICE figures.
The usual argument for EVs is that it's easier to replace a few power stations with something less polluting than it is to replace every car. It's also likely easier to do carbon sequestration and to filter particulates from a large industrial installation than from a few million tiny portable generators.
Examples: Ancient Greece / Macedonia, Roman Empire, Vikings. Lots of examples of highly successful civilisations that had high instances of homosexuality (Alexander the Great's wife complained that he'd rather sleep with his generals than with her) and seem to have done very well out of it.
Add to that, a lot of the most active ZFS developers work on the various OpenSolaris forks. A GPL'd version is completely useless to them. It's also not clear if Oracle even could release a GPL'd version. If they've taken any code from OpenZFS, then their version will include CDDL'd code that they don't own the copyright to, which would make relicensing impossible without replacing all of that code.