There was also the (really, really, really) ill-fated "Project Pink"; where Microsoft managed to take the limited, but quite popular and successful in its niche, product line they'd acquired from Danger/Sidekick and leave nothing but smoking ruins.
Wrong about Google's distribution terms; but very likely correct about the state that it will be in on the vast majority of the devices you can buy.
Given the...exciting quality...of handset vendor(and ARM SoC BSPs generally) GPL compliance; it seems very unlikely that they'll be more forthcoming about firmware based on BSD/MIT/similar licensed OS code.
Perhaps I'll end up being pleasantly surprised; but (at least in the context of the ARM SoC market) a highly permissive license could easily be the case that leaves the end user(or anyone who isn't purchasing in volumes large enough to get enthusiastic cooperation from the chipset vendor) in the worst situation.
With fully proprietary; and generally binary-only, OSes(Windows being the obvious example), vendors don't tend to provide OSS drivers; but they have to provide drivers that are more or less cleanly separated from the OS; because they don't have the right to distribute a modified version of the OS. You want to run Windows, you don't get to bodge some version of the NT kernel into a BSP, it has to work with stock NT plus your drivers, period.
With GPLed OSes, you can(and vendors frequently do, especially with all the deeply weird embedded variants) make nontrivial modifications to the OS; up to and including BSPs that are essentially forks with no interest in mainline support; but are theoretically obligated(and, while this has proven to be imperfect; it has resulted in many devices and chipsets gaining at least some degree of 3rd party support, or even being mainlined) to provide your customers with the changes you've made.
With BSD/MIT licensed OSes, you have no need to disclose anything about what you did to get the source OS working on your hardware; and their current attitude doesn't suggest that most of the ARM types will be interested in doing so out of the goodness of their hearts.
I certainly respect the rights of software authors to choose whatever license suits them; it's their software; and I have a personal fondness for the BSDs; but it is the case that Linux's GPL requirements have made 3rd party development a possibility on a wide variety of devices that would otherwise have remained closed(router firmwares, Android ROMs, etc.) while BSD support is considerably patchier outside of relatively well understood platforms and/or ones with genuinely cooperative vendors. The handset market, unfortunately, isn't a particularly good example of either; so I wouldn't be too optimistic about actually being able to run anything other than the vendor binaries on most of the hardware you'll actually be able to buy.
He's certainly abrasive; but his track record is markedly better than the people who spend most of their time claiming to be 'futurists' or other flavors of technological visionary. Unfortunately, the predictions he gets wrong are usually the situations where things got worse, faster, than anticipated(the most notable example is probably "Tivoization" and the more general rise of computers that are entirely under the control of whoever has the signing key; rather than merely being deeply unhelpful and requiring copious reverse engineering).
ReactOS is in sort of a tricky spot in terms of ever being the best option. Without the resources to chase full compatibility with whatever Microsoft feels like doing; your odds of getting all the drivers lined up and working for relatively new hardware aren't all that exciting(and, since the objective is binary compatibility with Windows drivers, not the development of ReactOS drivers, if the vendor's driver doesn't work you probably don't have any alternatives).
Legacy systems are more likely to work; but those are also more likely to be in the "wall it off from the internet and try not to touch anything" phase of their lives; which is deeply ugly; but generally a situation where you have a lot to lose and not much to gain by ripping out whatever antique version of Windows is currently there and replacing it with something else.
It's kind of a narrow niche. Especially if you have no objections to binary drivers(which you almost certainly don't, if you are even thinking about an OS intended for maximum Windows compatibility); Linux has a very good chance at working at least adequately well on new hardware faster than ReactOS does and while crufty old Windows can't be trusted in hostile environments, it can be isolated and kept on life support in various ways.
As much as people like to complain about video card costs; it should be fairly difficult for this nonsense to be nearly as expensive as the more traditional flavors of college sportsball.
And property values in the flight paths of airports tend to suggest that people very much dislike close proximity to operating aircraft. Airports tend to have enough clout to avoid being shoved out into the sticks entirely(though getting an expansion to an existing airport can be deeply fraught); but selling people on "helipads on every street corner"? Have fun with that.
As with a lot of annoying Microsoft things these days; the fact that you can't is more of a licensing issue than a technical one.
On the desktop, Windows 10 LTSB is the de-crapified version you actually want; but haha, volume-licensed enterprise SKUs only!
If you have the appropriate Windows Server version license; you can install "server core" or "nano server"; which have even more cut out; but while that can at least be purchased in single units; it's a fairly expensive way to declutter a workstation.
It took a while; but Microsoft did manage to disentangle a lot of the formerly mandatory bits and pieces; it's just that they seem loath to actually sell that to you unless they've exhausted all the alternatives.
Any particular reason why we should just assume that only those nice, 'anonymized', 'statistics' were for sale; or that the 'anonymizing' done wasn't as pitifully weak as it often is?
Shockingly enough, people seem to be willing to pay more for data that are more or less cosmetically obfuscated, and trivial to correlate with information from other sources; and less for data that are actually anonymous enough to be impossible to reconstruct.
Is there some sort of rule that vendor hostility becomes more acceptable as devices become smaller?
If the vendor specifically has to break the ability to remap a button; this fairly strongly implies that it was otherwise possible; and the only reason it is impossible now is because they don't want it to happen.
People tend not to feel the same way about fixed-function buttons in weaker devices because the limitations are more architectural than deliberate(and, if only thanks to a couple of decades of convergent evolution, there is often a reasonably sane quasi-default layout).
This case isn't about BB's patents(except in that access to some of them, in lieu of cash, might have been part of the royalties paid to Qualcomm); but you wouldn't have much of a royalties fight without some patents involved(in this industry; were these book publishers or authors, 'royalties' would imply copyrights; but aside from baseband code and drivers of very dubious quality, Qualcomm's IP reserves are largely patents).
I don't disagree with those suspicions on BB's future revenue sources; but this particular spat involves BB trying to reduce they amount they were paying Qualcomm, so while the favorable judgement means they get a payment now, the net flow of money is from BB to Qualcomm, just with a dispute about how large it should be. It is conveivable that they could 'patent troll' while still paying the other guy(if, say, they used some combination of threats to get Qualcomm parts well below the usual price; but still had to pay something for them); but unless this royalty adjustment is astonishingly good, it seems more like an attempt to beat back Qualcomm's own...enthusiastic...deployment of IP claims.
Now, since BB barely sells actual products anymore; this big exciting payout is likely to be hard to repeat; and then they'll come out trolling; but this specific case against Qualcomm looks like part of the general industry backlash against the exciting business of cellular modem patents. Qualcomm has had some antitrust trouble in multiple venues, is in court with several customers, and generally seems to have made themselves unpopular of late.
I can understand that keeping physical contraband from sneaking around a prison might be rather tricky; but it sounds like the admins were, perhaps literally, asleep at the switch if unauthorized devices and users were able to get network access without being noticed.
I'd be fairly shocked if the Americans and the British are 'more ethical'(Gamma Group LTD. certainly comes up in some unpleasant news); but if you sell product through established channels to deep-pocketed American military customers, say, your goods may well end up assisting some fairly awful people(our 'basically anyone who says they hate terrorists more than they hate us is a freedom pal!' policy has led to some ugly friendships); but you probably have less incentive to slum around with whatever cover-story the Al Jazeera journalists cooked up.
If you are hungrier for customers, either because your military isn't buying, or because you are seen as a second-stringer, odds are much better that you'll be aggressively looking for work in ways that make it considerably easier to run this sort of sting. Much the same as conventional weapons: it's not as though good, honest, American killing gear doesn't show up in all sorts of nasty places; but you are going to have a harder time attracting a high end defense contractor to your skeezy meeting in a downmarket hotel than you are a hungrier independent dealer who doesn't have wealthy, largely dependable, clients to spend time cultivating.
Arguably, it's the 'equivalent infrastructure' bit that is particularly unrealistic. Duplicating a set of software components well enough to allow for drop-in replacement is hard enough; but it's at least theoretically doable if the target isn't moving too fast; and it has been done with varying levels of success.
"Infrastructure", though, is something that can't exactly be copied at zero marginal cost; and requires substantially more(both in terms of money;and in terms of things like mapping data) than mere API interoperability.
"API compatible with Google Play Services 10.2" is to "Equivalent infrastructure" roughly what "Eucalyptus" is to "AWS". The one is a piece of software. The other is a great deal bigger.
Citation? At least the US, the FCC is very, very, humorless about anyone nosing in on the spectrum that has been declared the rightful dominion of the cell carriers. The only real exception is transient use of stingrays. Definitely don't bet against IT on the wifi; but attempting to tamper with 4G traffic is inviting a world of pain for rather minimal benefit.
Because one aspect of the 'more structured' is a handy mechanism for executing code on your system if you open it. If text editors habitually executed any shell scripts included in.txt files; we'd be nervous about those as well. Greater complexity is hardly completely safe, since it makes implementation of software capable of opening the file more complex; but that's a comparatively minor difference of degree compared to the difference between files types where automatic execution is a feature and ones where it's a bug.
Some outfits drop support alarmingly quickly; or take a 'if it isn't crashing to desktop more than once an hour, it's totally fine" approach to quality; but it helps that the games most likely to never get Ryzen support are the older ones, which are also the games targeted at the specs of older hardware.
If it turns out that, even for recent and future releases, only a couple of AMD's best-buddies publishers ever bother then there is a problem. If it's just older games, contemporary PCs are comfortably overpowered, by virtue of being years newer than what those games were developed to run on, so the problem will be largely irrelevant(contemporary Intel CPUs will be even more overpowered for those titles; but once you reach 'overpowered', you are dealing with seriously diminishing returns on performance).
Were we ever expecting Samsung to actually just toss all these things into the grinder? They had a fairly high end SoC, bunch of RAM and Flash, nice screens, etc. no reason to suspect that the PMIC itself was executing batteries. Why would you scrap something like that?
For 'brand' reasons, it wouldn't be a surprise to see them shunted off to some less-loved market; or even 'de-branded' and sold in more generic livery; but scrapped?
I agree that grovelling for solutions to oddball problems is annoying; but my experience has been that any OS puts you in that place from time to time.
If, say, Windows Update is throwing cryptic errors, it doesn't take too long to be instructed to 'Reset the BITS service to the default security descriptor'. Just open an elevated CMD shell and run "sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)", n00b.
OSX has the virtue of changing at least a few of the command line options that aren't pulled straight from BSD every version bump(changes related to user/directory structure seem to be particularly popular); and not all advice is clear on which versions it pertains to; which can be really annoying.
I don't disagree with the fact that, if a Linux system does something...unexpected...you may well deeply fail to enjoy finding the answer; but any time the automagic fails, regardless of OS, you are usually in for some pain(since, if the answer were trivial and unambigious, the automagic would probably still be working); and a trip to the command line, registry, PLists, or some combination is likely in your future.
If anything, it's the scary, hostile-looking OSes that are least risky in this regard because they never pretended to have automagic to help you in the first place; and so are simpler; and designed so that an unaided human can grind through everything themselves. That's a huge nuisance, which is why most OSes aren't like that; but fallible automatic failing is never pretty.
I'd be surprised to see Blizzard do either; but he did specify 'the source' rather than 'the IP'; and the two are (relatively) easily separable.
Given that, even at the time, most of the enthusiasm for Starcraft was for a combination of its play balance(having 3 actually-different sides without being horribly lopsided was pretty big news when the standard was two, often basically reskins of each other with a couple of flavor units) and overall style/art direction; I'm not sure who would be interested in just the engine; but Blizzard certainly could release it without giving up any control over the parts of the Starcraft 'IP' that are of actual value. Given the number of people who actually want to look at the code vs. the number of people who just want to play Starcraft, it would be a lot of trouble for not a lot of interest, but it needn't threaten the stuff that is actually worth something.
People rarely have a lot of love for the party in the position to charge them more; but the fact that a 'search company' apparently can't make any useful promises regarding where your ads will end up is probably not helping their position on this one.
Even in situations where everything is pretty banal; advertisers generally want some targeting of the impressions they are paying for to the audience they are trying to reach. If Google can't demonstrate an ability to avoid certain contexts on request, why would an advertiser believe that they are any more accurate or honest when it comes to targeting certain audiences?
Trump's relationship with the truth isn't so much interesting in that it's fairly casual; but in how self-destructive it seems to be.
People lying in order to advance their interests is an issue; but hardly unexpected or particularly abnormal. People who can't stop lying even when they'd be trivially better off keeping their mouths shut are a different matter. Something like the inagural crowd size thing: that's an idiotic lie. Trivially verifiable, hilariously petty; and completely unnecessary. He didn't lose much by it, since nobody actually seems to expect better; but he had virtually nothing to gain even if it had worked; and no reasonable expectation that it would work.
Slashdot Mirror
There was also the (really, really, really) ill-fated "Project Pink"; where Microsoft managed to take the limited, but quite popular and successful in its niche, product line they'd acquired from Danger/Sidekick and leave nothing but smoking ruins.
That one was...genuinely impressive.
Wrong about Google's distribution terms; but very likely correct about the state that it will be in on the vast majority of the devices you can buy.
Given the...exciting quality...of handset vendor(and ARM SoC BSPs generally) GPL compliance; it seems very unlikely that they'll be more forthcoming about firmware based on BSD/MIT/similar licensed OS code.
Perhaps I'll end up being pleasantly surprised; but (at least in the context of the ARM SoC market) a highly permissive license could easily be the case that leaves the end user(or anyone who isn't purchasing in volumes large enough to get enthusiastic cooperation from the chipset vendor) in the worst situation.
With fully proprietary; and generally binary-only, OSes(Windows being the obvious example), vendors don't tend to provide OSS drivers; but they have to provide drivers that are more or less cleanly separated from the OS; because they don't have the right to distribute a modified version of the OS. You want to run Windows, you don't get to bodge some version of the NT kernel into a BSP, it has to work with stock NT plus your drivers, period.
With GPLed OSes, you can(and vendors frequently do, especially with all the deeply weird embedded variants) make nontrivial modifications to the OS; up to and including BSPs that are essentially forks with no interest in mainline support; but are theoretically obligated(and, while this has proven to be imperfect; it has resulted in many devices and chipsets gaining at least some degree of 3rd party support, or even being mainlined) to provide your customers with the changes you've made.
With BSD/MIT licensed OSes, you have no need to disclose anything about what you did to get the source OS working on your hardware; and their current attitude doesn't suggest that most of the ARM types will be interested in doing so out of the goodness of their hearts.
I certainly respect the rights of software authors to choose whatever license suits them; it's their software; and I have a personal fondness for the BSDs; but it is the case that Linux's GPL requirements have made 3rd party development a possibility on a wide variety of devices that would otherwise have remained closed(router firmwares, Android ROMs, etc.) while BSD support is considerably patchier outside of relatively well understood platforms and/or ones with genuinely cooperative vendors. The handset market, unfortunately, isn't a particularly good example of either; so I wouldn't be too optimistic about actually being able to run anything other than the vendor binaries on most of the hardware you'll actually be able to buy.
He's certainly abrasive; but his track record is markedly better than the people who spend most of their time claiming to be 'futurists' or other flavors of technological visionary. Unfortunately, the predictions he gets wrong are usually the situations where things got worse, faster, than anticipated(the most notable example is probably "Tivoization" and the more general rise of computers that are entirely under the control of whoever has the signing key; rather than merely being deeply unhelpful and requiring copious reverse engineering).
ReactOS is in sort of a tricky spot in terms of ever being the best option. Without the resources to chase full compatibility with whatever Microsoft feels like doing; your odds of getting all the drivers lined up and working for relatively new hardware aren't all that exciting(and, since the objective is binary compatibility with Windows drivers, not the development of ReactOS drivers, if the vendor's driver doesn't work you probably don't have any alternatives).
Legacy systems are more likely to work; but those are also more likely to be in the "wall it off from the internet and try not to touch anything" phase of their lives; which is deeply ugly; but generally a situation where you have a lot to lose and not much to gain by ripping out whatever antique version of Windows is currently there and replacing it with something else.
It's kind of a narrow niche. Especially if you have no objections to binary drivers(which you almost certainly don't, if you are even thinking about an OS intended for maximum Windows compatibility); Linux has a very good chance at working at least adequately well on new hardware faster than ReactOS does and while crufty old Windows can't be trusted in hostile environments, it can be isolated and kept on life support in various ways.
As much as people like to complain about video card costs; it should be fairly difficult for this nonsense to be nearly as expensive as the more traditional flavors of college sportsball.
And property values in the flight paths of airports tend to suggest that people very much dislike close proximity to operating aircraft. Airports tend to have enough clout to avoid being shoved out into the sticks entirely(though getting an expansion to an existing airport can be deeply fraught); but selling people on "helipads on every street corner"? Have fun with that.
As with a lot of annoying Microsoft things these days; the fact that you can't is more of a licensing issue than a technical one.
On the desktop, Windows 10 LTSB is the de-crapified version you actually want; but haha, volume-licensed enterprise SKUs only!
If you have the appropriate Windows Server version license; you can install "server core" or "nano server"; which have even more cut out; but while that can at least be purchased in single units; it's a fairly expensive way to declutter a workstation.
It took a while; but Microsoft did manage to disentangle a lot of the formerly mandatory bits and pieces; it's just that they seem loath to actually sell that to you unless they've exhausted all the alternatives.
Any particular reason why we should just assume that only those nice, 'anonymized', 'statistics' were for sale; or that the 'anonymizing' done wasn't as pitifully weak as it often is?
Shockingly enough, people seem to be willing to pay more for data that are more or less cosmetically obfuscated, and trivial to correlate with information from other sources; and less for data that are actually anonymous enough to be impossible to reconstruct.
Is there some sort of rule that vendor hostility becomes more acceptable as devices become smaller?
If the vendor specifically has to break the ability to remap a button; this fairly strongly implies that it was otherwise possible; and the only reason it is impossible now is because they don't want it to happen.
People tend not to feel the same way about fixed-function buttons in weaker devices because the limitations are more architectural than deliberate(and, if only thanks to a couple of decades of convergent evolution, there is often a reasonably sane quasi-default layout).
Do you know what you pay 'royalties' on? Patents.
This case isn't about BB's patents(except in that access to some of them, in lieu of cash, might have been part of the royalties paid to Qualcomm); but you wouldn't have much of a royalties fight without some patents involved(in this industry; were these book publishers or authors, 'royalties' would imply copyrights; but aside from baseband code and drivers of very dubious quality, Qualcomm's IP reserves are largely patents).
I don't disagree with those suspicions on BB's future revenue sources; but this particular spat involves BB trying to reduce they amount they were paying Qualcomm, so while the favorable judgement means they get a payment now, the net flow of money is from BB to Qualcomm, just with a dispute about how large it should be. It is conveivable that they could 'patent troll' while still paying the other guy(if, say, they used some combination of threats to get Qualcomm parts well below the usual price; but still had to pay something for them); but unless this royalty adjustment is astonishingly good, it seems more like an attempt to beat back Qualcomm's own...enthusiastic...deployment of IP claims.
Now, since BB barely sells actual products anymore; this big exciting payout is likely to be hard to repeat; and then they'll come out trolling; but this specific case against Qualcomm looks like part of the general industry backlash against the exciting business of cellular modem patents. Qualcomm has had some antitrust trouble in multiple venues, is in court with several customers, and generally seems to have made themselves unpopular of late.
I can understand that keeping physical contraband from sneaking around a prison might be rather tricky; but it sounds like the admins were, perhaps literally, asleep at the switch if unauthorized devices and users were able to get network access without being noticed.
Since when is getting a slap on the wrist for your egregious surveillance practices "getting thrown under the bus"?
Could also be a budget/marketing style thing.
I'd be fairly shocked if the Americans and the British are 'more ethical'(Gamma Group LTD. certainly comes up in some unpleasant news); but if you sell product through established channels to deep-pocketed American military customers, say, your goods may well end up assisting some fairly awful people(our 'basically anyone who says they hate terrorists more than they hate us is a freedom pal!' policy has led to some ugly friendships); but you probably have less incentive to slum around with whatever cover-story the Al Jazeera journalists cooked up.
If you are hungrier for customers, either because your military isn't buying, or because you are seen as a second-stringer, odds are much better that you'll be aggressively looking for work in ways that make it considerably easier to run this sort of sting. Much the same as conventional weapons: it's not as though good, honest, American killing gear doesn't show up in all sorts of nasty places; but you are going to have a harder time attracting a high end defense contractor to your skeezy meeting in a downmarket hotel than you are a hungrier independent dealer who doesn't have wealthy, largely dependable, clients to spend time cultivating.
Arguably, it's the 'equivalent infrastructure' bit that is particularly unrealistic. Duplicating a set of software components well enough to allow for drop-in replacement is hard enough; but it's at least theoretically doable if the target isn't moving too fast; and it has been done with varying levels of success.
"Infrastructure", though, is something that can't exactly be copied at zero marginal cost; and requires substantially more(both in terms of money;and in terms of things like mapping data) than mere API interoperability.
"API compatible with Google Play Services 10.2" is to "Equivalent infrastructure" roughly what "Eucalyptus" is to "AWS". The one is a piece of software. The other is a great deal bigger.
Citation? At least the US, the FCC is very, very, humorless about anyone nosing in on the spectrum that has been declared the rightful dominion of the cell carriers. The only real exception is transient use of stingrays. Definitely don't bet against IT on the wifi; but attempting to tamper with 4G traffic is inviting a world of pain for rather minimal benefit.
Because one aspect of the 'more structured' is a handy mechanism for executing code on your system if you open it. If text editors habitually executed any shell scripts included in .txt files; we'd be nervous about those as well. Greater complexity is hardly completely safe, since it makes implementation of software capable of opening the file more complex; but that's a comparatively minor difference of degree compared to the difference between files types where automatic execution is a feature and ones where it's a bug.
Some outfits drop support alarmingly quickly; or take a 'if it isn't crashing to desktop more than once an hour, it's totally fine" approach to quality; but it helps that the games most likely to never get Ryzen support are the older ones, which are also the games targeted at the specs of older hardware.
If it turns out that, even for recent and future releases, only a couple of AMD's best-buddies publishers ever bother then there is a problem. If it's just older games, contemporary PCs are comfortably overpowered, by virtue of being years newer than what those games were developed to run on, so the problem will be largely irrelevant(contemporary Intel CPUs will be even more overpowered for those titles; but once you reach 'overpowered', you are dealing with seriously diminishing returns on performance).
Were we ever expecting Samsung to actually just toss all these things into the grinder? They had a fairly high end SoC, bunch of RAM and Flash, nice screens, etc. no reason to suspect that the PMIC itself was executing batteries. Why would you scrap something like that?
For 'brand' reasons, it wouldn't be a surprise to see them shunted off to some less-loved market; or even 'de-branded' and sold in more generic livery; but scrapped?
I agree that grovelling for solutions to oddball problems is annoying; but my experience has been that any OS puts you in that place from time to time.
If, say, Windows Update is throwing cryptic errors, it doesn't take too long to be instructed to 'Reset the BITS service to the default security descriptor'. Just open an elevated CMD shell and run "sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)", n00b.
OSX has the virtue of changing at least a few of the command line options that aren't pulled straight from BSD every version bump(changes related to user/directory structure seem to be particularly popular); and not all advice is clear on which versions it pertains to; which can be really annoying.
I don't disagree with the fact that, if a Linux system does something...unexpected...you may well deeply fail to enjoy finding the answer; but any time the automagic fails, regardless of OS, you are usually in for some pain(since, if the answer were trivial and unambigious, the automagic would probably still be working); and a trip to the command line, registry, PLists, or some combination is likely in your future.
If anything, it's the scary, hostile-looking OSes that are least risky in this regard because they never pretended to have automagic to help you in the first place; and so are simpler; and designed so that an unaided human can grind through everything themselves. That's a huge nuisance, which is why most OSes aren't like that; but fallible automatic failing is never pretty.
I'd be surprised to see Blizzard do either; but he did specify 'the source' rather than 'the IP'; and the two are (relatively) easily separable.
Given that, even at the time, most of the enthusiasm for Starcraft was for a combination of its play balance(having 3 actually-different sides without being horribly lopsided was pretty big news when the standard was two, often basically reskins of each other with a couple of flavor units) and overall style/art direction; I'm not sure who would be interested in just the engine; but Blizzard certainly could release it without giving up any control over the parts of the Starcraft 'IP' that are of actual value. Given the number of people who actually want to look at the code vs. the number of people who just want to play Starcraft, it would be a lot of trouble for not a lot of interest, but it needn't threaten the stuff that is actually worth something.
It's almost like Google has a search problem on their hands.
People rarely have a lot of love for the party in the position to charge them more; but the fact that a 'search company' apparently can't make any useful promises regarding where your ads will end up is probably not helping their position on this one.
Even in situations where everything is pretty banal; advertisers generally want some targeting of the impressions they are paying for to the audience they are trying to reach. If Google can't demonstrate an ability to avoid certain contexts on request, why would an advertiser believe that they are any more accurate or honest when it comes to targeting certain audiences?
Trump's relationship with the truth isn't so much interesting in that it's fairly casual; but in how self-destructive it seems to be.
People lying in order to advance their interests is an issue; but hardly unexpected or particularly abnormal. People who can't stop lying even when they'd be trivially better off keeping their mouths shut are a different matter. Something like the inagural crowd size thing: that's an idiotic lie. Trivially verifiable, hilariously petty; and completely unnecessary. He didn't lose much by it, since nobody actually seems to expect better; but he had virtually nothing to gain even if it had worked; and no reasonable expectation that it would work.
And I want a supply of square circles. Those should be about as easy to come by as 'promotions that are not ads'.