Make a list of major tech companies that have a significant investment in C++ code. Make a list of companies that are gcc contributors and companies that are clang contributors. You'll find a huge intersection between the first and third lists and a much smaller intersection between the first and second. You'll also find that most of the companies in the second list are also in the third.
I had it summed up to me quite well by a friend at ARM. He said that their customers basically come in two categories: those that don't care whether they use gcc or clang and those that won't allow GPLv3 code in the door. As a result, guess where they're investing all of their compiler resources. These days, I think most gcc development is done by RedHat, and even that are now investing in LLVM.
Breaking changes will probably be easier after modules are finalised. In a more modern language, you can have breaking changes by sticking a version directive at the top of a file and using that to select the correct version of the parser. Unfortunately, C++ uses the traditional C compilation model where compilation units are split across a load of files, some of which might not be writeable by the programmer, so trying to upgrade everything at once to a new version is a problem. Once modules are here, that coupling is reduced and it will be possible to expose interfaces that aren't necessarily declared in a header whose syntax matches the same version of the standard as the importing file.
What do you like about Windows 10? I had to set it up for my mother and, while I've done some work with MSR and am quite impressed with some of the technology that they've put into it, the UI is terrible. A few examples:
In the hour that I used it, I counted 7 different progress indicators. Consistency is one of the hallmarks of a good UI. Windows 10 fails spectacularly.
There is a new 'settings' app, which has a different look and feel to control panel. Settings are either there, or in the control panel. You need to check both to discover which (try configuring a trackpad: the settings are split between the two).
They have added a number of buttons that look like file icons, but expect a single click (because they're buttons, not file icons) and will trigger some action twice if you double click on them.
One of the most important aspects of a good UI is discoverability: a user, exploring the UI, should be able to find all of the functionality of a program. The control panel's default UI assumes that you know exactly why you're there. You need to change the view to get an interface that lets you see all of the options.
The search functionality is pretty unreliable for finding installed apps (though it will happily recommend apps from the store for you to buy).
It felt like GNOME or KDE back in the 1.x or pre-1 days, when there was no consistency and lots of known-bad UI decisions everywhere.
Security audits are not always useful. For example, I read the result of the security audit on Dovecot that Mozilla commissioned. They found three low-priority issues and one of those was not using FORTIFY_SOURCE. Here's the problem: FORTIFY_SOURCE does not catch any issues that cannot be caught by static analysis. If it improves security in your program, then it is only because you are not incorporating static analysis into your workflow, which is a really good way of writing insecure code.
You can address that by limiting liability if they follow best practices. For example:
Was the thing that was compromised the latest version, exploited with a zero-day vulnerability? If so, lower penalty.
Was the thing that was compromised able to access only data that the component actually needed to function? If so, lower penalty. Higher penalties for anything that was leaked beyond the minimum that the attacked component needed to access.
Did you retain data beyond what the originators of that data would reasonably expect? If so, higher penalties if it's leaked.
The goal isn't to require everyone to have perfect security, it's to have penalties for below-average security, and use that as an incentive to push the average upwards.
Seriously? It had some good explosions, but I tried finding a single point in the movie where the characters actions actually made sense given their backgrounds and motivations, and couldn't find a single one. Maybe if you've read the comics, there's enough extra backstory for it to make sense, but it was basically run, jump, do nonsensical thing, explosion, all the way through.
I'd be very surprised at 1:3. The highest estimates I've seen are about 15%. In my personal experience (living in fairly liberal university cities) it's about 10%. It's always a bit difficult to measure, because a lot of people simply don't advertise their sexuality in any way and some are in the closet, but neither 33% nor 4% sound particularly plausible.
I haven't seen an InfoWorld article for ages, and after reading their C++17 article, I remember why.
C++ seems to now have enough momentum that I can actually use new features. It wasn't until 2003-4 that C99 support was sufficiently widespread that people didn't complain if I used C99 features, and C++ had a huge ABI change around that time in the *NIX world that broke everything. These days, I'm already using C++17 features (finally, the language has decent support for multiple return values and tagged unions!).
Or you can use FreeBSD right now. Capsicum turns file descriptors into capabilities and as soon as you call cap_enter you lose all access to the global namespace and can only interact with external resources via existing capabilities (or ones that are given to you dynamically by another process).
You can also more or less view iOS as a capability system if you squint hard enough. They write ACLs dynamically to try to emulate a capability system (one of the motivations for Capsicum was looking at what Apple was doing with the TrustedBSD MAC framework and seeing how it could be done a lot more simply).
Develop security critical software only with architects, designers and coders that are understand security
One of the big problems, and a large part of the reason that we're in this mess, is that a lot of security-critical software wasn't security critical when it was written. Here's a simple example: libjpeg. This library was written as a reference implementation of the JPEG standard, back in 1991. It was expected to be used to compress photographs from scans and render the compressed photographs on the screen. It's not security critical, because it's dealing only with data that it produced for the user. Then a few years later, the web appeared and gained img tags that could render JPEG images. Now, every web browser is taking untrusted data and passing it through libjpeg. One arbitrary code execution vulnerability in libjpeg and your web browser is compromised (or, in a modern browser, the renderer process that's responsible for one or a small group of tabs is compromised - not much help when that's your gmail tab and now the attacker can take control of your Google account and use it to install malware on your Android phone).
Worse, a lot of this software was written with speed at all costs in mind. The reference MPEG implementation is a wonderful example. It detected errors in the header by simply dereferencing the pointer and catching the SIGSEGV. It eliminated branches on hot paths and made the code run fast enough for realtime display on the slow computers of the time. I'll leave it to your imagination how that can be exploited when an attacker provides the video (of course, you were expected to get MPEG videos only from VideoCDs and other trusted sources, so this didn't matter). This mindset is still very common. Consider GPU drivers. If your card runs 1% faster than your competition, you'll sell a million more units. If you make it 1% slower but remove a security hole, you lose a million sales. Everything is fine until WebGL comes along and random web pages can provide programs to try to attack your GPU drivers (and no, the WebGL verifier is not helpful here, because it assumes that those 3 million lines of C/C++ GPU driver are bug free).
Note that in some countries (e.g. Germany) the agency responsible for protecting domestic computer infrastructure and the agency responsible for attacking foreign computer infrastructure are different. In the USA, the NSA has dual missions, which puts them in a difficult position because if they find a bug in X and X is used both by the US and North Korea (or whoever) in critical positions, they have to decide whether it's more important to keep their attack tool or prevent their enemies from exploiting the vulnerability.
One of the interesting results of the Snowden disclosures has been that the NSA and their rivals have found largely disjoint sets of vulnerabilities, so it's not even clear that if you fixed all of the things the NSA found that you'd be less vulnerable to attack from (for example) China or Russia.
This might actually be the solution. Insurance has mitigated a lot of other risky behaviours. Insurance companies are (mostly) pretty good at quantifying risk and have a financial incentive to improve when they aren't. If they look at your company and say you're ten times more likely to suffer a data breach than your competitor, then they'll charge you at least ten times more for insurance. Eventually, it becomes a choice of spending the money on insurance or spending less money on improving security, at which point even beancounters can figure out that spending money on security is a good idea.
Same here, but it's also worth remembering Schneier's advice: if you sign up to netflix as netflix@example.com, there's a good chance that he can guess what email address you use for amazon! It's also good security if you use different email addresses for each service, because if one of them has poor security then whoever compromises them will try your username and password on a all of their services, and now they have two things that hopefully won't match.
Hotmail was a relatively small Sun customer. Remember that this was at the start of the.com boom, when all of the cool Internet startups were running Sun kit. They needed to bash Microsoft, because they were terrified that their customers would replace UNIX servers with NT servers on their corporate networks. To some degree, it even worked, given the number of companies that decided to migrate their servers to Linux/*BSD instead of Windows NT.
I assumed you were making a comment about recent printers because you used the present tense when you said 'The only problem with color laser printers is that they won't give photo-quality prints'. If your post had started 'The only problem with color laser printers is that 15 years ago they didn't give photo-quality prints' then I'd have read it very differently, but then it wouldn't have been making much of a point.
Yeah... no. The instructions specifically said that it won't have the full charge capacity until you do. Conditioning has nothing to do with the chemical part of the battery, it's entirely to calibrate the electronics that control the charge and discharge rates.
Kodi has been in the mainstream press a lot recently, because there are third-party add-ons that provide streaming from illegal sources and a bunch of providers have been selling 'Kodi Boxes' that have these preinstalled. Oh, and again because a few of these came with decidedly substandard power supplies that were a fire risk.
It's been on Slashdot a bunch of times, including at least one article about when they had to change the name from XBMC over trademark issues.
Basically, if you haven't come across Kodi, you've not been paying attention.
Is transcoding that big a deal? Even WiFi is fast enough for a few HD streams now, and if the NAS is on a wired connection then you're only using the WiFi spectrum one way. I just share my media via a read-only NFS / SMB / AFP for other devices to access, but I'm interested in what you get from something like Plex on top of this.
If this were true, then why would there be a ransomware problem?
Several reasons. The first is that you don't need anonymity for ransoms, you need the perception of anonymity. Ransom demands are possible when the criminal believes that they can receive the payment anonymously, there is less of a requirement that this belief be well founded.
The second is that you actually don't really need anonymity for ransomware at all, you just need to be able to get the money past law enforcement boundaries. If, for example, I were in North Korea and released ransomware, then it wouldn't matter that everyone could see where the money went to, I'd still be safe from anyone arresting me.
The third is that tracking the money is only part of the problem. If a law enforcement organisation determines that money sent to a bank account was illegal, then they can freeze the account and they can reverse the transaction. There is no way for a third party to freeze a bitcoin account, so you can watch everything that the criminal spends money on, but you can't stop them spending it (unless you can somehow persuade everyone not to accept money from that wallet).
Finally, even without cryptocurrencies in the mix, money laundering is a thing. Bitcoin makes this relatively easy: I can send my bitcoins to an exchange, turn them into some other currency, and then take that money to another bank account and then back to an exchange and turn it into Bitcoin. Now there's no record in the public ledger that the money that I withdrew and put back on the block chain are the same. Money went into a pot and then came out again. You can avoid even that with mixer services, where you deposit an amount in bitcoin and withdraw the same amount (or a fraction less). All that the blockchain then knows is that 1,000 people each put 1 bitcoin in and 1,000 people each got 1 bitcoin out (in a different wallet, if they weren't idiots) and so there's no easy way of tying the individual money trails together. If you can get the records associated with the mixers, then you can recreate this, but there's no guarantee that they even keep useful records.
That's not quite true. Lowering the nominal tax rate will reduce the differential in actual rate between companies that engage in active tax avoidance and those that don't. That may end up making smaller businesses (that can't afford armies of accountants and lawyers to figure out the loopholes) slightly more competitive.
Exactly. I don't mind that they reduce performance to extend battery life, I do mind that they don't provide a way of seeing the battery status. On macOS, you can go to System Information and it will tell you the cycle count and full charge capacity of the battery. If the cycle count is below the rated maximum (I think it's 1,000 complete discharge cycles these days - mine's done 378 after 4 years of use) and its full-charge capacity is no longer at least 80% of the capacity when new, then they'll replace it.
I can't speak for the iPhone ones, but I recently got a third-party battery for an old MacBook Pro. Even from new and after doing all of the conditioning steps, it gets about half to two thirds of the battery life that the original got. Batteries are definitely not all equal.
Slashdot Mirror
Make a list of major tech companies that have a significant investment in C++ code. Make a list of companies that are gcc contributors and companies that are clang contributors. You'll find a huge intersection between the first and third lists and a much smaller intersection between the first and second. You'll also find that most of the companies in the second list are also in the third.
I had it summed up to me quite well by a friend at ARM. He said that their customers basically come in two categories: those that don't care whether they use gcc or clang and those that won't allow GPLv3 code in the door. As a result, guess where they're investing all of their compiler resources. These days, I think most gcc development is done by RedHat, and even that are now investing in LLVM.
Breaking changes will probably be easier after modules are finalised. In a more modern language, you can have breaking changes by sticking a version directive at the top of a file and using that to select the correct version of the parser. Unfortunately, C++ uses the traditional C compilation model where compilation units are split across a load of files, some of which might not be writeable by the programmer, so trying to upgrade everything at once to a new version is a problem. Once modules are here, that coupling is reduced and it will be possible to expose interfaces that aren't necessarily declared in a header whose syntax matches the same version of the standard as the importing file.
What do you like about Windows 10? I had to set it up for my mother and, while I've done some work with MSR and am quite impressed with some of the technology that they've put into it, the UI is terrible. A few examples:
It felt like GNOME or KDE back in the 1.x or pre-1 days, when there was no consistency and lots of known-bad UI decisions everywhere.
Security audits are not always useful. For example, I read the result of the security audit on Dovecot that Mozilla commissioned. They found three low-priority issues and one of those was not using FORTIFY_SOURCE. Here's the problem: FORTIFY_SOURCE does not catch any issues that cannot be caught by static analysis. If it improves security in your program, then it is only because you are not incorporating static analysis into your workflow, which is a really good way of writing insecure code.
Was the thing that was compromised the latest version, exploited with a zero-day vulnerability? If so, lower penalty.
Was the thing that was compromised able to access only data that the component actually needed to function? If so, lower penalty. Higher penalties for anything that was leaked beyond the minimum that the attacked component needed to access.
Did you retain data beyond what the originators of that data would reasonably expect? If so, higher penalties if it's leaked.
The goal isn't to require everyone to have perfect security, it's to have penalties for below-average security, and use that as an incentive to push the average upwards.
I've not come across any C++17 bugs in clang / libc++. Perhaps you could list some of the major highlights from the 'large amount of bugs'.
Seriously? It had some good explosions, but I tried finding a single point in the movie where the characters actions actually made sense given their backgrounds and motivations, and couldn't find a single one. Maybe if you've read the comics, there's enough extra backstory for it to make sense, but it was basically run, jump, do nonsensical thing, explosion, all the way through.
To be fair though, no one wanted to be Ma-Ti with the power of Heart when they grew up.
I'd be very surprised at 1:3. The highest estimates I've seen are about 15%. In my personal experience (living in fairly liberal university cities) it's about 10%. It's always a bit difficult to measure, because a lot of people simply don't advertise their sexuality in any way and some are in the closet, but neither 33% nor 4% sound particularly plausible.
C++ seems to now have enough momentum that I can actually use new features. It wasn't until 2003-4 that C99 support was sufficiently widespread that people didn't complain if I used C99 features, and C++ had a huge ABI change around that time in the *NIX world that broke everything. These days, I'm already using C++17 features (finally, the language has decent support for multiple return values and tagged unions!).
Or you can use FreeBSD right now. Capsicum turns file descriptors into capabilities and as soon as you call cap_enter you lose all access to the global namespace and can only interact with external resources via existing capabilities (or ones that are given to you dynamically by another process).
You can also more or less view iOS as a capability system if you squint hard enough. They write ACLs dynamically to try to emulate a capability system (one of the motivations for Capsicum was looking at what Apple was doing with the TrustedBSD MAC framework and seeing how it could be done a lot more simply).
Develop security critical software only with architects, designers and coders that are understand security
One of the big problems, and a large part of the reason that we're in this mess, is that a lot of security-critical software wasn't security critical when it was written. Here's a simple example: libjpeg. This library was written as a reference implementation of the JPEG standard, back in 1991. It was expected to be used to compress photographs from scans and render the compressed photographs on the screen. It's not security critical, because it's dealing only with data that it produced for the user. Then a few years later, the web appeared and gained img tags that could render JPEG images. Now, every web browser is taking untrusted data and passing it through libjpeg. One arbitrary code execution vulnerability in libjpeg and your web browser is compromised (or, in a modern browser, the renderer process that's responsible for one or a small group of tabs is compromised - not much help when that's your gmail tab and now the attacker can take control of your Google account and use it to install malware on your Android phone).
Worse, a lot of this software was written with speed at all costs in mind. The reference MPEG implementation is a wonderful example. It detected errors in the header by simply dereferencing the pointer and catching the SIGSEGV. It eliminated branches on hot paths and made the code run fast enough for realtime display on the slow computers of the time. I'll leave it to your imagination how that can be exploited when an attacker provides the video (of course, you were expected to get MPEG videos only from VideoCDs and other trusted sources, so this didn't matter). This mindset is still very common. Consider GPU drivers. If your card runs 1% faster than your competition, you'll sell a million more units. If you make it 1% slower but remove a security hole, you lose a million sales. Everything is fine until WebGL comes along and random web pages can provide programs to try to attack your GPU drivers (and no, the WebGL verifier is not helpful here, because it assumes that those 3 million lines of C/C++ GPU driver are bug free).
Note that in some countries (e.g. Germany) the agency responsible for protecting domestic computer infrastructure and the agency responsible for attacking foreign computer infrastructure are different. In the USA, the NSA has dual missions, which puts them in a difficult position because if they find a bug in X and X is used both by the US and North Korea (or whoever) in critical positions, they have to decide whether it's more important to keep their attack tool or prevent their enemies from exploiting the vulnerability.
One of the interesting results of the Snowden disclosures has been that the NSA and their rivals have found largely disjoint sets of vulnerabilities, so it's not even clear that if you fixed all of the things the NSA found that you'd be less vulnerable to attack from (for example) China or Russia.
This might actually be the solution. Insurance has mitigated a lot of other risky behaviours. Insurance companies are (mostly) pretty good at quantifying risk and have a financial incentive to improve when they aren't. If they look at your company and say you're ten times more likely to suffer a data breach than your competitor, then they'll charge you at least ten times more for insurance. Eventually, it becomes a choice of spending the money on insurance or spending less money on improving security, at which point even beancounters can figure out that spending money on security is a good idea.
Yes, that's his point. The set of features that any given thing does not have is infinite.
Same here, but it's also worth remembering Schneier's advice: if you sign up to netflix as netflix@example.com, there's a good chance that he can guess what email address you use for amazon! It's also good security if you use different email addresses for each service, because if one of them has poor security then whoever compromises them will try your username and password on a all of their services, and now they have two things that hopefully won't match.
Hotmail was a relatively small Sun customer. Remember that this was at the start of the .com boom, when all of the cool Internet startups were running Sun kit. They needed to bash Microsoft, because they were terrified that their customers would replace UNIX servers with NT servers on their corporate networks. To some degree, it even worked, given the number of companies that decided to migrate their servers to Linux/*BSD instead of Windows NT.
I assumed you were making a comment about recent printers because you used the present tense when you said 'The only problem with color laser printers is that they won't give photo-quality prints'. If your post had started 'The only problem with color laser printers is that 15 years ago they didn't give photo-quality prints' then I'd have read it very differently, but then it wouldn't have been making much of a point.
Yeah... no. The instructions specifically said that it won't have the full charge capacity until you do. Conditioning has nothing to do with the chemical part of the battery, it's entirely to calibrate the electronics that control the charge and discharge rates.
Kodi has been in the mainstream press a lot recently, because there are third-party add-ons that provide streaming from illegal sources and a bunch of providers have been selling 'Kodi Boxes' that have these preinstalled. Oh, and again because a few of these came with decidedly substandard power supplies that were a fire risk.
It's been on Slashdot a bunch of times, including at least one article about when they had to change the name from XBMC over trademark issues.
Basically, if you haven't come across Kodi, you've not been paying attention.
Is transcoding that big a deal? Even WiFi is fast enough for a few HD streams now, and if the NAS is on a wired connection then you're only using the WiFi spectrum one way. I just share my media via a read-only NFS / SMB / AFP for other devices to access, but I'm interested in what you get from something like Plex on top of this.
If this were true, then why would there be a ransomware problem?
Several reasons. The first is that you don't need anonymity for ransoms, you need the perception of anonymity. Ransom demands are possible when the criminal believes that they can receive the payment anonymously, there is less of a requirement that this belief be well founded.
The second is that you actually don't really need anonymity for ransomware at all, you just need to be able to get the money past law enforcement boundaries. If, for example, I were in North Korea and released ransomware, then it wouldn't matter that everyone could see where the money went to, I'd still be safe from anyone arresting me.
The third is that tracking the money is only part of the problem. If a law enforcement organisation determines that money sent to a bank account was illegal, then they can freeze the account and they can reverse the transaction. There is no way for a third party to freeze a bitcoin account, so you can watch everything that the criminal spends money on, but you can't stop them spending it (unless you can somehow persuade everyone not to accept money from that wallet).
Finally, even without cryptocurrencies in the mix, money laundering is a thing. Bitcoin makes this relatively easy: I can send my bitcoins to an exchange, turn them into some other currency, and then take that money to another bank account and then back to an exchange and turn it into Bitcoin. Now there's no record in the public ledger that the money that I withdrew and put back on the block chain are the same. Money went into a pot and then came out again. You can avoid even that with mixer services, where you deposit an amount in bitcoin and withdraw the same amount (or a fraction less). All that the blockchain then knows is that 1,000 people each put 1 bitcoin in and 1,000 people each got 1 bitcoin out (in a different wallet, if they weren't idiots) and so there's no easy way of tying the individual money trails together. If you can get the records associated with the mixers, then you can recreate this, but there's no guarantee that they even keep useful records.
"Lowering taxes" isn't going to do anything
That's not quite true. Lowering the nominal tax rate will reduce the differential in actual rate between companies that engage in active tax avoidance and those that don't. That may end up making smaller businesses (that can't afford armies of accountants and lawyers to figure out the loopholes) slightly more competitive.
Exactly. I don't mind that they reduce performance to extend battery life, I do mind that they don't provide a way of seeing the battery status. On macOS, you can go to System Information and it will tell you the cycle count and full charge capacity of the battery. If the cycle count is below the rated maximum (I think it's 1,000 complete discharge cycles these days - mine's done 378 after 4 years of use) and its full-charge capacity is no longer at least 80% of the capacity when new, then they'll replace it.
I can't speak for the iPhone ones, but I recently got a third-party battery for an old MacBook Pro. Even from new and after doing all of the conditioning steps, it gets about half to two thirds of the battery life that the original got. Batteries are definitely not all equal.