Not really, it's in the setting "Controlling input when commands from MCAS conflict with inputs from pilot: Obey pilot? Obey MCAS?". The "Obey MCAS?" option should simply be removed, then the other settings simply control how often a reportable incident will occur and not whether the aircraft will crash. At least as long as the pilots themselves know how to actually fly the aircraft, and if they don't that's not a problem that the aircraft's control software should be even trying to solve because, as a software engineer by profession, is that trying to do that's equivalent to the halting problem.
The problem isn't implementation bugs, it's the basic design that gives the autopilot control authority over the pilot. This exact sort of accident has been with us since the introduction of the first A320 (the first fly-by-wire aircraft where the autopilot could overrule the pilot's control inputs). The fix is in 2 parts:
The flight control systems should always implement the pilot's inputs regardless of what the computers think, unless the pilot's actively told it to disengage his set of controls.
Teach your pilots that their first and overriding priority is to fly the plane. Everything else that isn't preventing them from flying the plane takes a back seat. As long as the plane's still flying you've got time and space to figure everything else out. Once it stops flying, all bets are off.
It's prudent exactly because "I don't have time to read your email." translates to "Your email isn't a priority for me at this time.". Technically I do read all my email, at least as far as the sender and subject, but the first thing I'm looking for when I skim it is "Is this email relevant to something that's one of my priorities right now, and if so which one?". If it is, that email has the priority of whatever it's related to and I'll get to replying to it when my priorities permit. Which means if it's a low priority item I won't be working on for some time, don't expect a quick reply. If it's a high priority for you but not for me, either you or your manager need to stop bothering me and go talk to my manager about getting relative priorities adjusted (in fact this should've happened when the priority for the item was set, that this is coming up indicates a severe lack of communication on the part of one or more of the managers involved). I'll be happy to help bring it to my manager's attention, provide estimates on how quickly things can be done and what the effects of shuffling priorities will be, but don't expect me to go upending my priorities without my manager knowing about it and approving it. Note: bug reports already have a (really high) permanent place on my priority list and get a same-day or faster response (if nothing else, indicating how long I think it'll take to nail the cause down and get a handle on a fix). Regular updates on progress and ETA from me are required and I rarely miss sending them out so be really sure you've checked your folders and there really isn't a relevant update before bugging me about progress.
Personal email I handle on the same basis, and I feel absolutely no obligation to respond to email merely because you sent it to me. If I don't respond it's usually because either I don't know you and your email had nothing in it to interest me, or I know you and don't want to talk to you about whatever your email was about (or possibly at all, depending). The exceptions involve things like my being in the ICU in a coma, and if you're close enough friends to expect a response from me you're already on the list of people who'll get notified about things like that in some way.
Yes, I'm an old codger who refuses to be nickel-and-dimed to death by people wanting "just a few minutes of my time". Time is ultimately the only currency we have, and I'm as careful with it as I am with the dollars in my bank accounts. My friends understand this and we've worked out a mutually-acceptable balance. Failing to understand it, in turn, is one of the fastest known ways to get put into my twit filter.
I can think of several ways this can happen. Malware in the browser is one, no need to steal a password if you can use the currently logged-in session to change the password to a known value. Social engineering of OkC's support, resetting the email address and password through that channel won't generate a change-of-address confirmation even if the normal process does. A compromise of OkC's systems that OkC hasn't noticed yet (or doesn't want to admit to because of the likely effect on their business). Given the lack of security typical of this kind of site and how much their business model discourages strong identification of users, I have to consider an account with them to be at-risk from the moment it's created.
So why can't Cerberus use the SMS Retriever API for their functionality? For what they're doing they don't need to see every SMS message or call log entry on the device, they just need to see and respond to the single SMS message sent by their servers which is exactly what the Retriever API is designed for. It requires a loop, it'd be nice if there was a way for an app to register a permanent retriever so that loop wasn't necessary, but it shouldn't require a half-decent Android developer more than a day or two to code up the functionality needed. All these devs are doing is throwing a hissy fit instead of acknowledging why Google found these restrictions necessary and working within them (or working with Google to implement just the functionality needed). I suddenly feel a need to research any app or company complaining about this to see exactly why they're so upset about losing access to a data stream that it doesn't seem they should care about in the first place.
For a debt, no. More precisely, they can't consider the debt in default or attempt to collect on it if you've offered and continue to offer payment in full in legal tender and they refuse to accept it. The only thing lacking is teeth: a law stating that if a creditor is found to have begun collection or legal action on a debt where legal tender has been offered in payment and refused the creditor must bear all the debtor's costs and fees in the matter.
Up-front transactions, where the merchant hasn't turned over the goods yet so no debt exists, would take additional changes in the law.
At-will is fine, but that means you can tell your employer "I won't be in tomorrow, I'm quitting." as you leave. It doesn't mean you don't give them any indication you're quitting. At-will is not the same as ghosting.
For hourly employees, yes time-and-a-half for work over 40 hours a week. Salaried is a different equation because you're (supposedly) being paid for the job, not the hours you put in like hourly are. So, the basic offer is $X for a job that involves 40 hours a week worth of effort on average. The thing that hits the employer here is that since the pay is for the job, not the hours, they don't get to pay you less just because you didn't put in the expected hours that week. So if they offered $8K/month ($96K/year) and they want to work you 60 hours a week for 3+ months straight, they have to pay you $12K/month every month for the entire year (they expected 60 hours/week for more than 13 weeks out of 52, which means they're expecting you to work 60-hour weeks on a regular basis). That makes it hurt even more to try and overwork salaried employees.
I'm of the opinion overtime should always be optional. Management should staff for the expected workload, not expect everyone on staff to do the job of 2 people. But management doesn't like that, that raises their costs and lowers their profits. And they have the upper hand in bargaining, because they can replace any individual employee. That's why we formed unions, so that the collective power of the employer was matched by the collective power of the employees.
Overtime pay also evened the playing field. Employers could overwork their employees only at a progressively higher and higher cost. That made it cheaper to simply staff appropriately rather than demand 60- and 80-hour weeks regularly. Salaried status removed that balance.
I'm of the mind that labor law should be changed to state that the salary offer for a salaried employee was an offer for a standard 40-hour week on average and that a requirement from the employer to work more than that on a regular basis constituted a change in the terms of employment that would require paying the employee in proportion to the extra hours worked (eg. a 60-hour week is 150% of the original agreement's demand so the employer is required to pay 150% of the original agreement's salary offer). "Regular basis" could be defined by weekly work time over a given period, eg. requiring more than 40 hours per week for 6 weeks in any 12-week period or 13 weeks in any 52-week period would constitute "regular basis" for that period. Employers would then have to balance the cost of overworking their existing staff vs. the cost of adding staff sufficient for the workload.
I don't recall Microsoft's implementation violating any of the published specifications. It didn't conform to what the advertisers wanted (opt-out implementation with the default being "allow to be tracked"), but it doesn't violate the spec. To quote from the spec (Tracking Preference Expression W3C Editor's Draft 07 March 2016):
A user agent MUST have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the user's decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred, but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred.
Microsoft's browser is advertised as having this preference set by default, so the decision to use it by a user, knowing what the default was, would imply they wished to have DNT set by default. That this would result in less tracking than advertisers wish... doesn't seem to me to be within the scope of the standard. Every time users (as opposed to advertisers) have been surveyed, the results seem to heavily support an opt-in model where tracking is not permitted unless a user opts in to tracking (similar to the results for email where users heavily favor a model that does not permit email contact unless the user opts in to email contact).
If I don't distribute the modified version, do I need to accept a license to get the right to use it? My understanding is that the FSF's position is that, for all the *GPL family of licenses, you don't need to accept the license just to run the software because you aren't distributing copies to anyone else and all the internal copies needed to run it are covered by the permissions copyright law gives you. I recall this same issue of trying to prohibit certain uses of *GPL'd software by it's recipient coming up before, and the answer was always "A pure copyright license isn't the vehicle to do that.".
The prohibition on providing the software as a service appears to conflict with, or at least be trivially bypassed by, section 9 which states that to run the software you don't have to accept the terms of the license. Section 9 conforms with the law as written: running the software, and making the copies needed to run it, are explicitly not an infringement of copyright (USC Title 17 section 117(a)(1)). If I don't have to accept the license to do something, I'm not bound by it's terms merely because I do that something.
Because what they're distributing isn't the AGPL. That clause is there to prevent someone from modifying the terms of the AGPL but still presenting it as the AGPL, deceiving recipients about the terms they can expect.
All that's correct. OTOH, that license doesn't cover continuing access to Wikimedia's servers and network. I'd think it'd only make good business sense, if Wikipedia's such a valuable source of information for Amazon, for Amazon to have a contract in place insuring continued server and network capacity for Wikimedia to provide for Amazon's needs and for continued editor/moderator support. The ongoing cost for Amazon would probably be negligible, the direct benefits should be obvious and the benefits in terms of public relations and goodwill would be immense. Which can all be summed up in the old rule: "Don't kill the goose that lays the golden eggs."
Pretty much this. I have a simple policy: it doesn't matter whether I believe the call is legitimate or not, I do not give out information or try to resolve a problem when it's the other party calling me. I note who it is and what they claim the problem is, then I call the contact number from my own records for that person/company (from my address book, the credit card itself, the last bill, their Web site from my bookmarks, etc.) and ask to be connected to the correct department for the problem. Now I know I'm talking to the right people and not a scammer. This usually takes all of a minute or two, and saves me from ever falling for even the most convincing scams.
If you're truly interested in tracking down the source of calls, see about a toll-free incoming line handled by software like Asterisk and get your caller's identity from the billing information rather than CID. That's too expensive for me, though.
The whole point of a stunt fall is to look like a real fall but not produce the kinds of impacts that'd result in injury. It makes sense that trying to fake a fall that way would result in the watch deciding it wasn't a real fall. There wouldn't have been, for instance, the kind of sharp, sudden impact you see in a real fall because the stuntperson would be spreading the impact out over time so they wouldn't break bones.
It'd also need connections to the PCIe bus. That's easy enough to get, but it means a lot of traces going into a single chip that oughtn't have that many incoming traces. I'm thinking it'd be easier to modify the EFI firmware and hide a small extra processor in the southbridge chip.
The law wouldn't apply to headsets/earpieces (the most common case here) because while they have a Bluetooth address they aren't connected to the Internet either directly or indirectly (section 1798.91.05(b)).
Except swatting calls aren't typically "I see a guy holding an AR-15 at some woman in the window". They're more like "A guy with a several AR-15s and shotguns just ran into a house and is I can hear shots, WHY AREN'T YOU SENDING ANYONE OVER OMG A BULLET JUST HIT MY HOUSE!".
Then there's going to be gunshots going off which will tell the recon people that this isn't a false alarm, no? Shouldn't take long to assess that situation and tell the SWAT guys it's a go. On the other hand if you receive a call like that and there aren't any gunshots going off then a quiet recon will let you figure out where the shooter is without tipping him off and scaring him into starting shooting again, or let you determine that it's a false alarm and there never was a shooter before bystanders get killed.
The extra checks for the "swatting concerns" flag should be the default checks the cops do before responding. For a medical emergency for instance there's no need for an armed response. If there's a threat of violence the one thing you don't want to do right off is an armed, forced entry, you start by doing recon on the target to figure out what's currently going on before deciding on tactics which if it's a false call will give plenty of opportunity to establish that there's no current apparent threat of violence (and if it's for real, it gives you an idea where and what the threats are without startling the bad guys into doing something you don't want them doing like taking hostages).
Replacing human combatants with robots is a bad policy decision in general. The reason is simple: one of the main reasons restraining governments from waging war is the cost in terms of their own citizens killed in the fighting, removing humans from the fighting removes that restraint. We'll have enough problems with governments that already don't care about their own citizens, we don't need to add every other government to that list until we figure out another way to discourage them from starting wars any time they don't get their way.
On top of that, the possibility of robots being subverted by attackers isn't in any way overstated nor are the reactions to the possibility over-reacting. Look at our computer networks today and try to convince me that we can somehow make botnets and malware vanish overnight, and then picture a world where "distributed denial of service attack" translates to "security guards shooting any human who enters the shopping mall".
Part of why COBOL's so efficient at fixed-point math is that the hardware it runs on has fixed-point math instructions and the compiler uses them directly. The x86 instruction set doesn't include those (it has support for BCD math but the instructions are relegated to the "rarely used, don't bother optimizing" category and you have to keep track of the decimal point separately) and the available compilers don't generate code to use them so the math routines aren't very efficient. Frankly though I'd love to see fixed-point types as a compiler- and instruction-set-supported data type, I've written way too much code that had to deal with money that could've made use of them.
Simple solution: don't trust any one source. Even if they're supposedly impeccable. Look for corroboration from multiple independent sources (and make sure they're really independent and not all getting their information from the same source). For instance if you have a video of someone checking into a hotel with a compromising companion, look for corroboration from the hotel's records, hotel staff who should have interacted with them, and the person's credit-card records. This is what we used to do before people got lazy and started believing everything they were told without question.
For me, the replacements are search results and bookmarks in the browser, with URLs being strictly a machine-usable form used inside software. Whose site I can reach through a given bookmark (or what content is at that page) and whether it's owned by who I think it is (via SSL certificate match usually, although DANE would be better) is everything most users want, the rest should be the equivalent of an IP address.
Slashdot Mirror
Not really, it's in the setting "Controlling input when commands from MCAS conflict with inputs from pilot: Obey pilot? Obey MCAS?". The "Obey MCAS?" option should simply be removed, then the other settings simply control how often a reportable incident will occur and not whether the aircraft will crash. At least as long as the pilots themselves know how to actually fly the aircraft, and if they don't that's not a problem that the aircraft's control software should be even trying to solve because, as a software engineer by profession, is that trying to do that's equivalent to the halting problem.
The problem isn't implementation bugs, it's the basic design that gives the autopilot control authority over the pilot. This exact sort of accident has been with us since the introduction of the first A320 (the first fly-by-wire aircraft where the autopilot could overrule the pilot's control inputs). The fix is in 2 parts:
It's prudent exactly because "I don't have time to read your email." translates to "Your email isn't a priority for me at this time.". Technically I do read all my email, at least as far as the sender and subject, but the first thing I'm looking for when I skim it is "Is this email relevant to something that's one of my priorities right now, and if so which one?". If it is, that email has the priority of whatever it's related to and I'll get to replying to it when my priorities permit. Which means if it's a low priority item I won't be working on for some time, don't expect a quick reply. If it's a high priority for you but not for me, either you or your manager need to stop bothering me and go talk to my manager about getting relative priorities adjusted (in fact this should've happened when the priority for the item was set, that this is coming up indicates a severe lack of communication on the part of one or more of the managers involved). I'll be happy to help bring it to my manager's attention, provide estimates on how quickly things can be done and what the effects of shuffling priorities will be, but don't expect me to go upending my priorities without my manager knowing about it and approving it. Note: bug reports already have a (really high) permanent place on my priority list and get a same-day or faster response (if nothing else, indicating how long I think it'll take to nail the cause down and get a handle on a fix). Regular updates on progress and ETA from me are required and I rarely miss sending them out so be really sure you've checked your folders and there really isn't a relevant update before bugging me about progress.
Personal email I handle on the same basis, and I feel absolutely no obligation to respond to email merely because you sent it to me. If I don't respond it's usually because either I don't know you and your email had nothing in it to interest me, or I know you and don't want to talk to you about whatever your email was about (or possibly at all, depending). The exceptions involve things like my being in the ICU in a coma, and if you're close enough friends to expect a response from me you're already on the list of people who'll get notified about things like that in some way.
Yes, I'm an old codger who refuses to be nickel-and-dimed to death by people wanting "just a few minutes of my time". Time is ultimately the only currency we have, and I'm as careful with it as I am with the dollars in my bank accounts. My friends understand this and we've worked out a mutually-acceptable balance. Failing to understand it, in turn, is one of the fastest known ways to get put into my twit filter.
I can think of several ways this can happen. Malware in the browser is one, no need to steal a password if you can use the currently logged-in session to change the password to a known value. Social engineering of OkC's support, resetting the email address and password through that channel won't generate a change-of-address confirmation even if the normal process does. A compromise of OkC's systems that OkC hasn't noticed yet (or doesn't want to admit to because of the likely effect on their business). Given the lack of security typical of this kind of site and how much their business model discourages strong identification of users, I have to consider an account with them to be at-risk from the moment it's created.
Your CPU could be "sold" on a subscription basis, if it can't verify that you've paid your subscription your hardware won't power up.
So why can't Cerberus use the SMS Retriever API for their functionality? For what they're doing they don't need to see every SMS message or call log entry on the device, they just need to see and respond to the single SMS message sent by their servers which is exactly what the Retriever API is designed for. It requires a loop, it'd be nice if there was a way for an app to register a permanent retriever so that loop wasn't necessary, but it shouldn't require a half-decent Android developer more than a day or two to code up the functionality needed. All these devs are doing is throwing a hissy fit instead of acknowledging why Google found these restrictions necessary and working within them (or working with Google to implement just the functionality needed). I suddenly feel a need to research any app or company complaining about this to see exactly why they're so upset about losing access to a data stream that it doesn't seem they should care about in the first place.
For a debt, no. More precisely, they can't consider the debt in default or attempt to collect on it if you've offered and continue to offer payment in full in legal tender and they refuse to accept it. The only thing lacking is teeth: a law stating that if a creditor is found to have begun collection or legal action on a debt where legal tender has been offered in payment and refused the creditor must bear all the debtor's costs and fees in the matter.
Up-front transactions, where the merchant hasn't turned over the goods yet so no debt exists, would take additional changes in the law.
At-will is fine, but that means you can tell your employer "I won't be in tomorrow, I'm quitting." as you leave. It doesn't mean you don't give them any indication you're quitting. At-will is not the same as ghosting.
For hourly employees, yes time-and-a-half for work over 40 hours a week. Salaried is a different equation because you're (supposedly) being paid for the job, not the hours you put in like hourly are. So, the basic offer is $X for a job that involves 40 hours a week worth of effort on average. The thing that hits the employer here is that since the pay is for the job, not the hours, they don't get to pay you less just because you didn't put in the expected hours that week. So if they offered $8K/month ($96K/year) and they want to work you 60 hours a week for 3+ months straight, they have to pay you $12K/month every month for the entire year (they expected 60 hours/week for more than 13 weeks out of 52, which means they're expecting you to work 60-hour weeks on a regular basis). That makes it hurt even more to try and overwork salaried employees.
I'm of the opinion overtime should always be optional. Management should staff for the expected workload, not expect everyone on staff to do the job of 2 people. But management doesn't like that, that raises their costs and lowers their profits. And they have the upper hand in bargaining, because they can replace any individual employee. That's why we formed unions, so that the collective power of the employer was matched by the collective power of the employees.
Overtime pay also evened the playing field. Employers could overwork their employees only at a progressively higher and higher cost. That made it cheaper to simply staff appropriately rather than demand 60- and 80-hour weeks regularly. Salaried status removed that balance.
I'm of the mind that labor law should be changed to state that the salary offer for a salaried employee was an offer for a standard 40-hour week on average and that a requirement from the employer to work more than that on a regular basis constituted a change in the terms of employment that would require paying the employee in proportion to the extra hours worked (eg. a 60-hour week is 150% of the original agreement's demand so the employer is required to pay 150% of the original agreement's salary offer). "Regular basis" could be defined by weekly work time over a given period, eg. requiring more than 40 hours per week for 6 weeks in any 12-week period or 13 weeks in any 52-week period would constitute "regular basis" for that period. Employers would then have to balance the cost of overworking their existing staff vs. the cost of adding staff sufficient for the workload.
I don't recall Microsoft's implementation violating any of the published specifications. It didn't conform to what the advertisers wanted (opt-out implementation with the default being "allow to be tracked"), but it doesn't violate the spec. To quote from the spec (Tracking Preference Expression W3C Editor's Draft 07 March 2016):
Microsoft's browser is advertised as having this preference set by default, so the decision to use it by a user, knowing what the default was, would imply they wished to have DNT set by default. That this would result in less tracking than advertisers wish... doesn't seem to me to be within the scope of the standard. Every time users (as opposed to advertisers) have been surveyed, the results seem to heavily support an opt-in model where tracking is not permitted unless a user opts in to tracking (similar to the results for email where users heavily favor a model that does not permit email contact unless the user opts in to email contact).
If I don't distribute the modified version, do I need to accept a license to get the right to use it? My understanding is that the FSF's position is that, for all the *GPL family of licenses, you don't need to accept the license just to run the software because you aren't distributing copies to anyone else and all the internal copies needed to run it are covered by the permissions copyright law gives you. I recall this same issue of trying to prohibit certain uses of *GPL'd software by it's recipient coming up before, and the answer was always "A pure copyright license isn't the vehicle to do that.".
The prohibition on providing the software as a service appears to conflict with, or at least be trivially bypassed by, section 9 which states that to run the software you don't have to accept the terms of the license. Section 9 conforms with the law as written: running the software, and making the copies needed to run it, are explicitly not an infringement of copyright (USC Title 17 section 117(a)(1)). If I don't have to accept the license to do something, I'm not bound by it's terms merely because I do that something.
Because what they're distributing isn't the AGPL. That clause is there to prevent someone from modifying the terms of the AGPL but still presenting it as the AGPL, deceiving recipients about the terms they can expect.
All that's correct. OTOH, that license doesn't cover continuing access to Wikimedia's servers and network. I'd think it'd only make good business sense, if Wikipedia's such a valuable source of information for Amazon, for Amazon to have a contract in place insuring continued server and network capacity for Wikimedia to provide for Amazon's needs and for continued editor/moderator support. The ongoing cost for Amazon would probably be negligible, the direct benefits should be obvious and the benefits in terms of public relations and goodwill would be immense. Which can all be summed up in the old rule: "Don't kill the goose that lays the golden eggs."
Pretty much this. I have a simple policy: it doesn't matter whether I believe the call is legitimate or not, I do not give out information or try to resolve a problem when it's the other party calling me. I note who it is and what they claim the problem is, then I call the contact number from my own records for that person/company (from my address book, the credit card itself, the last bill, their Web site from my bookmarks, etc.) and ask to be connected to the correct department for the problem. Now I know I'm talking to the right people and not a scammer. This usually takes all of a minute or two, and saves me from ever falling for even the most convincing scams.
If you're truly interested in tracking down the source of calls, see about a toll-free incoming line handled by software like Asterisk and get your caller's identity from the billing information rather than CID. That's too expensive for me, though.
The whole point of a stunt fall is to look like a real fall but not produce the kinds of impacts that'd result in injury. It makes sense that trying to fake a fall that way would result in the watch deciding it wasn't a real fall. There wouldn't have been, for instance, the kind of sharp, sudden impact you see in a real fall because the stuntperson would be spreading the impact out over time so they wouldn't break bones.
It'd also need connections to the PCIe bus. That's easy enough to get, but it means a lot of traces going into a single chip that oughtn't have that many incoming traces. I'm thinking it'd be easier to modify the EFI firmware and hide a small extra processor in the southbridge chip.
The law wouldn't apply to headsets/earpieces (the most common case here) because while they have a Bluetooth address they aren't connected to the Internet either directly or indirectly (section 1798.91.05(b)).
Then there's going to be gunshots going off which will tell the recon people that this isn't a false alarm, no? Shouldn't take long to assess that situation and tell the SWAT guys it's a go. On the other hand if you receive a call like that and there aren't any gunshots going off then a quiet recon will let you figure out where the shooter is without tipping him off and scaring him into starting shooting again, or let you determine that it's a false alarm and there never was a shooter before bystanders get killed.
The extra checks for the "swatting concerns" flag should be the default checks the cops do before responding. For a medical emergency for instance there's no need for an armed response. If there's a threat of violence the one thing you don't want to do right off is an armed, forced entry, you start by doing recon on the target to figure out what's currently going on before deciding on tactics which if it's a false call will give plenty of opportunity to establish that there's no current apparent threat of violence (and if it's for real, it gives you an idea where and what the threats are without startling the bad guys into doing something you don't want them doing like taking hostages).
Replacing human combatants with robots is a bad policy decision in general. The reason is simple: one of the main reasons restraining governments from waging war is the cost in terms of their own citizens killed in the fighting, removing humans from the fighting removes that restraint. We'll have enough problems with governments that already don't care about their own citizens, we don't need to add every other government to that list until we figure out another way to discourage them from starting wars any time they don't get their way.
On top of that, the possibility of robots being subverted by attackers isn't in any way overstated nor are the reactions to the possibility over-reacting. Look at our computer networks today and try to convince me that we can somehow make botnets and malware vanish overnight, and then picture a world where "distributed denial of service attack" translates to "security guards shooting any human who enters the shopping mall".
Part of why COBOL's so efficient at fixed-point math is that the hardware it runs on has fixed-point math instructions and the compiler uses them directly. The x86 instruction set doesn't include those (it has support for BCD math but the instructions are relegated to the "rarely used, don't bother optimizing" category and you have to keep track of the decimal point separately) and the available compilers don't generate code to use them so the math routines aren't very efficient. Frankly though I'd love to see fixed-point types as a compiler- and instruction-set-supported data type, I've written way too much code that had to deal with money that could've made use of them.
Simple solution: don't trust any one source. Even if they're supposedly impeccable. Look for corroboration from multiple independent sources (and make sure they're really independent and not all getting their information from the same source). For instance if you have a video of someone checking into a hotel with a compromising companion, look for corroboration from the hotel's records, hotel staff who should have interacted with them, and the person's credit-card records. This is what we used to do before people got lazy and started believing everything they were told without question.
For me, the replacements are search results and bookmarks in the browser, with URLs being strictly a machine-usable form used inside software. Whose site I can reach through a given bookmark (or what content is at that page) and whether it's owned by who I think it is (via SSL certificate match usually, although DANE would be better) is everything most users want, the rest should be the equivalent of an IP address.