Have to agree with that, sadly. In any other industry it would take real courage to release something that's so far behind the competition and missing so many defacto standard features it's not even funny, let alone to charge a considerable premium for it as well. Fortunately for Apple they're in the IT industry and they still have enough die-hard fans that the HomePod is almost certainly going to sell out and generate billions of dollars for them (mostly in off-source tax havens, naturally). On the plus side, at least you can be reasonably sure that Apple isn't just going to hand over all of your data over to the NSA et al if they so much as glance in the general direction of the data centre - although given they will need access to it in order to process it and thus can't as easily hide behind user encryption I suspect they'll hand it all over without a fight upon receipt of a suitable court order.
Still, I can't imagine they'd have ever released such a poor product under Steve Jobs' tenure though, especially after the supposedly lacklustre reception of the iPhone X, and don't think Apple's is going to be doing itself any favours if it continues to release half-finished products while letting other product lines stagnate. Even die-hard fans have their limits.
Yep, it's different strokes for different folks, or countries in this case. Within a given market - the US or China, say - you can take some averages to provide a fixed price that can be applied across the board, typically making more from some demographics and potentially even running some at a loss, but trying to do so when you have radically different infrastructure, population densities, salaries, and costs of living just isn't going to work. The EU kind of gets away with it for some things because there's not all that much of a divergence across the EU member states, but trying to charge the same Dollar price for the same product or service in countries as different as the US and China just isn't going to be a viable business model as one will either be far too expensive or will be running at a massive loss.
"Reasonable diagnostic or repair functions by an independent repair provider" to me implies that your typical Joe doesn't have to be capable of doing it, but if you take it along to a suitablely equipped store they can do so for a nominal fee without damage to any additional parts other than easily replaceable on-time-snap-fix connectors. Basically, that's going to mean an end to simply replacing a proper chassis with glue, but after that it's all down to the interpretation of the letter and spirit of the legislation as to how many tools like spudgers and the degree of part-granuality that are required. Needless to say there's going to be quite a difference between manufacturers and repairers on this unless the legislation starts getting into the minutae of defining a line between components (like chips) and replaceable parts (boards with chips surface-mounted on them).
You can't really do a fair comparison of the national averages either as there probably is some bias between those using the streaming services that must have the disposable income to pay for it (most likely on the relatively higher Beijing average salaries) and those without (most likely on provincial area average salaries), which will also be further offset against the higher costs of living in Beijing vs. in the provinces. That $1424/month in Beijing won't help you pay for streaming services if you're paying out $1400/month on living essentials, but if person on the average $4,700/year salary is only spending $300/month on essentials out in the provinces they're going to have more left over for a streaming service.
I do think OP has a valid point though, regardless of average salary and disposable income levels. The cheaper a given service is, the more individuals' disposable incomes will support the outlay at which point it will start competing against all the other non-essential items that a given individual wants. Sooner or later, that's going to be below the point at which they're prepared to go legit to avoid the hassle of dodgy download sites and risk (relatively slim as it is, if done right) of getting caught. Perhaps the media producers and providers need to consider taking it on the chin by trimming their profits for a few years to help convince more people to go legit, because the chances are probably pretty good they'll keep using them if the prices don't go up too sharply a few years down the road.
The difference here seems to be the corruption angle; the EU is claiming that Qualcomm abused its position to lock out other vendors by sweetening the pot with cash, which is completely different from Apple approaching potential vendors in a kind of tender to see who offers the best bang for their buck then signing an exclusive supply deal as a result. Offering 100m chips at $1 each as a sole supplier is legal; offering 100m chips at $1.10 each plus $10m in cash to *be* the sole supplier is not - even though the total exchange (100m chips vs. $100m) is the same in both cases. My take is that if the EU just thought that Qualcomm was abusing their dominant market position then Apple may be able to get off the hook as being just another Qualcomm customer, but if they're pushing the corruption angle then the law on that is very clear; both offering and accepting a bribe are against the law and will be prosecuted - and Apple should have been *well* aware of the cash in hand / kickback part of the legislation.
Quite. Every single company ethics training course I have ever done in the EU makes it very clear that both offering *and* accepting a bribe is a huge no-no and that both can carry some very severe penalties if you are caught. Depending on the circumstances, those penalties currently include things like large fines, jail time and forfeiture of any assets paid for using a bribe (including your home) for the individuals involved, plus their employer being barred from government contracts if they were found negligent too. The devil will be in the details of the contracts, but if the EU sees Qualcomm's activities as a bribe under anti-corruption legislation then I wouldn't be surprised if they announce that they are going after Apple as well pretty soon.
Citation needed, and no, the US Army's claims that lack supporting evidence do not count - especially given they generally include the word "may".
Sure, DJI is definitely doing *some* data collection (as are most of the action cam/drone systems, either directly through the device or through on-line accounts associated with it) because they tell you so, but they're also claiming to be actively taking steps to improve enduser privacy and have blocked third party apps that have been caught doing so. Like MS Windows' telemetry, it's 100% clear that some data is being collected, but the actual extent of it seems to be based mostly speculation and rumour rather than fact and I've yet to see any really definitive articles that quantify with actual proof the scope of what is being collected and what countermeasures a privacy concious user might take to minimise the "damage" (and any operational compromises those countermeasures might entail). For instance, you claim that DJI is tracking location data in realtime using your phone, which is certainly possible, but the handset-drone comms uses the controller radio transmitter and the phone is USB tethered, so you should be able to put the phone into flight mode and simulate being in an area with no reception - or even just *be* in an area with no reception to prevent that from happening - unless they retrospectively upload it later, but again, I've not seen any definitive articles with evidence to back this up.
So, for anyone considering a drone purchase or that already has one and is getting concerned about the levels of tracking, does anyone have any decent links on this?
I don't think there's going to be an IPO (or ICO for that matter, given the number of companies jumping on that bandwagon), at least not in the near future. According to CNBC they might also be up for sale. I'm sure there would be some white knight willing to try and ride to the rescue, but at this point I fear it's going to take more than lower prices and a couple of new mounting options to turn things around. More likely they'll either end up part of some tech multi-national like Softbank or grabbed for their camera tech and patent portfolio by one of the larger drone manufacturers - Parrot or Yunneec, perhaps.
Yes, I do realise that - but it doesn't change the situation that *all* the BSD devs were kept out of the loop regardless of which family they work on. If you consider that there is still a lot of overlap between the two teams in terms of the code and contributors, then it would be kind of hard for FreeBSD to be making changes and testing them - especially if they wanted to roll them out publically like Linux did - without at least some of the OpenBSD devs either being in the loop or figuring out that something was up - and that then becomes a risk of premature and uncontrolled disclosure. Yes, it's possible that the FreeBSD security team could have kept everything under wraps, but from Google's point of view that's not the question they would have been considering; they'd have been considering how likely it was each potential insider was to result in a breach of the embargo. We now know FreeBSD wasn't in the loop, and we have to think they might consider that Theo might be a problem for maintaining the embargo, so regardless of whether they just treated all of BSD as a single entity or that the "Chinese walls" between the two teams wouldn't be strong enough, the end result is the same - a lot of BSD users, in all families, in a race to secure systems before the exploits hit.
That's exactly my reasoning. By comparison the Pentium recall was easy; die and pin-out compatible CPUs were still in production, but even for a partial recall here it's likely Intel would have to not only dust off old silicon designs, but the associated fabrication processes and packages as well. And that's before you start to factor in the higher proportion of CPUs now that are not really end-user, or even workshop replaceable, because they are phyically attached to motherboards rather than socketed. Their cheapest option has got to be to fight this all the way through the courts - during which time many of the CPUs will be retired - and then in the worst case pay up the legal fees and some lip-service compensation to anyone who can still find their receipts.
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans. Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either. Google's Project Zero team presumably had discussions with Intel and select others they felt they could trust about what was required to address the problem and how long it would take, and that group collectively agreed on the original release date of January 9th, plus who else to notify and when. Clearly that larger group did not include anyone in the BSD camp.
Standing up for your principles can have a cost attached, and I suspect we've just seen what that was for Theo and the BSD developers.
He's not wrong, both on the recall (which I'm not holding my breath on - I fully expect Intel to fight that to the bitter end given how much more painful than the Pentium replacements that would be for them) and the handling of the entire situation. There's clearly been a very high bar set betweeen those who were given the heads-up and those who were not, especially amongst service providers where it appears that only the *really* big players were in the loop. In the case of BSD devs specifically being left out of the loop though, perhaps Theo needs to take Linus' advice to Intel and a good hard look in the mirror as I seem to recall a similar incident not so long ago where the BSD devs were in the loop, but Theo refused to play ball and turned it into a free for all. I don't have the slightest problem with Theo standing up for his principles, but to do so without expecting there to be some rather obvious blowback should there be a similar situation in the future is rather naive, to say the least.
Which is pretty much the advice that was given while this was still in the submission queue; get a small laptop or a tablet and keyboard combo. Two comments and/thread. Why this made the front page - as a full story no-less - is beyond me, maybe they're fresh out of Trump and Bitcoin stories and were getting desparate to justify their salary or something...
That's where the geneticists come in, and this is covered in the article too. Even in *extremely* remote tribes - those in Brazil, for instance - there is genetic evidence of interbreeding with adjacent tribes, who interbreed with their adjacent tribes, and so on. Just because Tribe A has never mingled directly with true outsiders, doesn't mean their cousins in Tribe B, don't have cousins over in Tribe C that don't do so; by land for the Amazonian tribes, by sea (Polynesians, etc.) for the Aborigine. Once you start factoring in breeding by wider-ranging performers, traders, explorers, and (of course!) militaries and raiders, it starts becoming more and more likely that no one is truly isolated from everyone else for long. Obviously Chang's work is just a mathematical model and his numbers are the result of that, but it does seem to correlate very closely with genetic evidence so, while there will always be outliers, for the majority of the global population at least he's probably not all that far out of the ball park.
A genetic dead end is actually quite likely, statistically speaking. Any statistician could tell you that you are the decendant of *every* person who lived beyond a certain point back in time because family trees must ultimately start to have the same person in multiple branches. What's more surprising is just how quickly that happens, and (mathematically at least) how many people must have lived but who's line died out. According to Joseph Chang, a statistician at Yale, the figures are just 600 years for everyone currently alive in Europe to have a common ancestor and around 3,400 for everyone in the world. Those timescales were corroborated by geneticists Peter Ralph and Graham Coop in 2013 based on a study of genetic records. What's even less intuitive is that, according to Chang, how many people from history - like the two early North American infants - appear to have no living descendants today, per the linked article:
Chang’s calculations get even weirder if you go back a few more centuries. A thousand years in the past, the numbers say something very clear, and a bit disorienting. One-fifth of people alive a millennium ago in Europe are the ancestors of no one alive today. Their lines of descent petered out at some point, when they or one of their progeny did not leave any of their own. Conversely, the remaining 80 percent are the ancestor of everyone living today. All lines of ancestry coalesce on every individual in the 10th century.
If that's the case after just 1,000 years, it seems quite reasonable that many, many, more lines would have existed and died out in the preceeding 10,000 or so. Especially if you were to start factoring in the more tribal nature of communities and the increased susceptibility to famine, disease, conflict, natural disasters, and so on that results.
Whether Intel knew about it before Google told them is an interesting point, and almost certainly one that will come up when (not if!) this sees the inside of a courtroom. If they knew, or even suspected, there was a potential exploit they could have silently fixed it in future CPU designs and hoped for the best. Given the timescales involved with a chip design, and the costs of fixing flaws later in the process, it's going to be quite telling to see when Intel manages to get a CPU that is immune to the problem onto the shelves and whether there are any obvious delays in shipping them.
As stands, they are almost certainly going to be launching their next generation of chips complete with the flaw and going head-to-head against a resurgent AMD Ryzen that they will be conceeding 20-30% of potential performance to on patched systems for some critical workloads like DB servers. That's going to cost them. Realistically, the generation after that is going to be a fair way down the design process too (not too far from taping out), so they're either going to have to ship that with the flaw as well, delay it to fix the problem, or ship a fixed CPU on schedule which strongly implies they've known about this much longer than six months. Either way, that's going to cost them too, and that's before you start factoring in potential damages that might be awarded by the courts.
Actually, it's kind of in the middle. The problem isn't really that Intel tried to take a shortcut and boost performance with speculative execution, it's that they tried to take too big a shortcut and dropped some (all?) of the bounds checking as well. Since bounds checking provides security, and they must know this, they basically took a design decision to roll the dice with potential security flaws in exchange for a couple of extra perforance points and, potentially, a slightly simpler design.
The current approach is to do any bounds checking *after* the speculative execution in the event that the branch is to be executed, which is what enables the kernel memory to be leaked to userspace programmes. The secure way of doing it would be to do the bounds checking *during* the speculative execution, just as you would with normal execution, and in the event of a page fault fall back to the non-speculative execution approach. That would still be slightly slower, but not as bad as forcing the non-speculative execution approach every time, which is what the patches have now enforced.
It's a deliberate design decision, they should have known what the risks were, and there are a growing number of real world instances of applications showing repeatable ~30% performance hits directly attributable to the "fixes" (I've seen one myself firsthand that resulting in a public transport time tabling system failing). It might not work out so lucrative for an individual John Q. Public in a class action lawsuit, but it's starting to look quite likely that Intel is going to get reamed in the courts over this if they can't come up with a better workaround P.D.Q.
Given the geography, "past Miami" probably means over the Glades, which is almost certainly below the maximum population density requirement, but Cuba did raise my eyebrows too. I think the clue is actually in the bit that says "thread a safe path southward", which implies a rather narrow launch corridor. Keep in mind that by the time the rocket even gets from the Cape to Miami it's travelling pretty quickly, so if there is a problem with the trajectory it could easily be outside the permitted corridor before a human has a chance to react. An on-board system could fire the detonators, igniting any high explosives and propellant within milliseconds of the rocket crossing a GPS "fence", and probably wouldn't preclude someone in Mission Control doing a manual destruct were one to be required either. You're still going to have the risk of falling debris hitting something on the ground, but that's prettty slim given the available mass, how much of it will be vaporized in the blast, and the size of the debris field increasing exponentially with altitude.
This flaw has been known about since at least October, and probably even sooner since early code to fix it starting coming out in November, which makes it seem *highly* likely that he was aware of the it and the potential impact when he took the decision to commit to the November sale. Also, as CEO, there's no way that he can plausibly claim "I didn't know about it" like the two Equifax execs who executed a stock sale just before their breach announcement did without coming across as completely incompetent and unfit for the CEO role. This reeks of insider trading, and after the outcry over the Equifax execs I can't imagine that the SEC isn't going to want to take a good hard look at this stock sale as well.
I'm sure his vested options will pay for some really good lawyers but, even so, forfeiting his job could be the least of his problems.
A lot of modern CPU speed comes from speculative execution of code in branches. In simple terms, if the CPU sees what looks like a loop it will assume it's going to be going round the loop again, look at the execution queue, and start working on any memory fetches, loading of registers, etc.so any the data is right there in the on-chip cache when needed. What seems to be happening with the flaw is that the kernel memory that should be hidden might be accessible during that speculative execution phase and can be copied before the speculative code execution is commited.
The performance hit from the fix comes if you have a system call to the OS kernel inside that loop, as the fix requires that all that data be flushed to hide kernel memory space from the user memory space every time you switch from usermode to kernel mode and back again. That seems to imply that if your code has a tight loop that makes multiple calls to the OS kernel, then you've not only lost all the performance benefits of the speculative execution and cache, but you've also had to sacrifice CPU cycles to flush it in the first place. If your code loop is being executed millions, or even billions, of times - not uncommon for some tasks - then, yeah, you could well be looking at a double-digit percentage performance hit.
This. Without being privy to the closed discussions about how to engineer the patch (which AMD was clearly a part of) we have no way of knowing whether this wasn't the agreed approach. It's not like AMD would really want Intel making the decision over whether or not each of their CPU SKUs were vulnerable, and I doubt Intel would want to make that call either - they've got more pressing matters than trying to exploit AMD CPUs to deal with and they'd have to assume AMD would eat their lunch in court if they got one wrong. Time will tell though, I'm expecting some more details to come out on this aspect of it once the embargo lifts, and I doubt AMD will be shy about it if they think Intel tried to stiff them when they do.
I think that's actually going to depend more on the OS than the vendor. The available comments, urgency, and secrecy indicates a major hardware security issue being worked around, and both Apple and Microsoft have older OSs versions that are still officially in support for security patches, so this should therefore qualify. I wouldn't put it past either of them to neglect to provide the necessary switch for those older versions in an attempt to encourage people to upgrade to their current release.
One other thing that I have noticed from the Linux patch is that it is applied by default without any attempt to tie it into the use of some other feature like hardware virtualisation which raises the distinct possibility that it might be a more general problem, and quite possibly something that could be leveraged by a malicious userspace app. If that is the case, then it's potentially a vector for malware to compromise a system which would mean it would be a bad idea to disable the code on *any* system, regardless of whether it's multiuser or not. In that situation, I'd actually kind of expect Apple and Microsoft to be thinking long and hard about whether they want the typical home user to have control or not, even before you take their "we know best" mindsets into consideration.
Linux users don't even need to compile a custom kernel (although if performance *really* matters you should probably be doing so as a matter of course) as there's a boot time option in the that can be set to disable the new Page Table Isolation mode, "nopti". Without knowing the performance hit for a specific usage case and the nature of the flaw its currently impossible to say whether using it is going to be a good idea or not, but it's nice that they at least thought to include the option. Pretty sure BSD will do the same, but feel free to place your bets on commercial operating system vendors...
Probably the same reason why they can have a nuclear weapons programme; their priorities over where to spend their miniscule GDP are completely and utterly fscked up. They do send a few of their most trusted elites overseas to study, but mostly I suspect it's down to the black market and envelopes stuffed with used notes. Just as there were a lot of Soviet weapons scientists ready to fly to Pyongyang rather than face poverty after the USSR collapsed, there are almost certainly lot of black hats willing to train the appointed NORKs in the darker side of cracking.
There's also the useful idiot / scapegoat angle, of course. A government that has trained the DPRK's hackers and an understanding of the way the DPRK operates essentially has a deniable cyberweapon they can point wherever they want just by leaking some appropriate data on the target. It's not hard to think of a few countries that might consider that black budget money well spent.
When I started using Android years ago. I was literally the only one. Now, iPhone users are the exceptions.
I've been firmly in the Android camp for years too (since Froyo), but I think that likely depends a great deal on your circle of acquaintances. I work in IT and civil engineering but spend a lot of my spare time doing photography, visiting galleries, and mixing with people more on the artistic/creative end of the spectrum. There's a fair bit of overlap between the two groups (quite a few in STEM fields are also into photography), but in general the former are almost exclusively Android users and the latter almost exclusively Apple, with those like myself that straddle the two groups being those more likely to be the exceptions in a given gathering. That division doesn't really surprise me; Apple marketing clearly puts style pretty high up their feature list, Android phone marketing tends to focus more the specs, so I guess they all know their target audience and are playing to it.
Slashdot Mirror
Have to agree with that, sadly. In any other industry it would take real courage to release something that's so far behind the competition and missing so many defacto standard features it's not even funny, let alone to charge a considerable premium for it as well. Fortunately for Apple they're in the IT industry and they still have enough die-hard fans that the HomePod is almost certainly going to sell out and generate billions of dollars for them (mostly in off-source tax havens, naturally). On the plus side, at least you can be reasonably sure that Apple isn't just going to hand over all of your data over to the NSA et al if they so much as glance in the general direction of the data centre - although given they will need access to it in order to process it and thus can't as easily hide behind user encryption I suspect they'll hand it all over without a fight upon receipt of a suitable court order.
Still, I can't imagine they'd have ever released such a poor product under Steve Jobs' tenure though, especially after the supposedly lacklustre reception of the iPhone X, and don't think Apple's is going to be doing itself any favours if it continues to release half-finished products while letting other product lines stagnate. Even die-hard fans have their limits.
Yep, it's different strokes for different folks, or countries in this case. Within a given market - the US or China, say - you can take some averages to provide a fixed price that can be applied across the board, typically making more from some demographics and potentially even running some at a loss, but trying to do so when you have radically different infrastructure, population densities, salaries, and costs of living just isn't going to work. The EU kind of gets away with it for some things because there's not all that much of a divergence across the EU member states, but trying to charge the same Dollar price for the same product or service in countries as different as the US and China just isn't going to be a viable business model as one will either be far too expensive or will be running at a massive loss.
"Reasonable diagnostic or repair functions by an independent repair provider" to me implies that your typical Joe doesn't have to be capable of doing it, but if you take it along to a suitablely equipped store they can do so for a nominal fee without damage to any additional parts other than easily replaceable on-time-snap-fix connectors. Basically, that's going to mean an end to simply replacing a proper chassis with glue, but after that it's all down to the interpretation of the letter and spirit of the legislation as to how many tools like spudgers and the degree of part-granuality that are required. Needless to say there's going to be quite a difference between manufacturers and repairers on this unless the legislation starts getting into the minutae of defining a line between components (like chips) and replaceable parts (boards with chips surface-mounted on them).
You can't really do a fair comparison of the national averages either as there probably is some bias between those using the streaming services that must have the disposable income to pay for it (most likely on the relatively higher Beijing average salaries) and those without (most likely on provincial area average salaries), which will also be further offset against the higher costs of living in Beijing vs. in the provinces. That $1424/month in Beijing won't help you pay for streaming services if you're paying out $1400/month on living essentials, but if person on the average $4,700/year salary is only spending $300/month on essentials out in the provinces they're going to have more left over for a streaming service.
I do think OP has a valid point though, regardless of average salary and disposable income levels. The cheaper a given service is, the more individuals' disposable incomes will support the outlay at which point it will start competing against all the other non-essential items that a given individual wants. Sooner or later, that's going to be below the point at which they're prepared to go legit to avoid the hassle of dodgy download sites and risk (relatively slim as it is, if done right) of getting caught. Perhaps the media producers and providers need to consider taking it on the chin by trimming their profits for a few years to help convince more people to go legit, because the chances are probably pretty good they'll keep using them if the prices don't go up too sharply a few years down the road.
The difference here seems to be the corruption angle; the EU is claiming that Qualcomm abused its position to lock out other vendors by sweetening the pot with cash, which is completely different from Apple approaching potential vendors in a kind of tender to see who offers the best bang for their buck then signing an exclusive supply deal as a result. Offering 100m chips at $1 each as a sole supplier is legal; offering 100m chips at $1.10 each plus $10m in cash to *be* the sole supplier is not - even though the total exchange (100m chips vs. $100m) is the same in both cases. My take is that if the EU just thought that Qualcomm was abusing their dominant market position then Apple may be able to get off the hook as being just another Qualcomm customer, but if they're pushing the corruption angle then the law on that is very clear; both offering and accepting a bribe are against the law and will be prosecuted - and Apple should have been *well* aware of the cash in hand / kickback part of the legislation.
Quite. Every single company ethics training course I have ever done in the EU makes it very clear that both offering *and* accepting a bribe is a huge no-no and that both can carry some very severe penalties if you are caught. Depending on the circumstances, those penalties currently include things like large fines, jail time and forfeiture of any assets paid for using a bribe (including your home) for the individuals involved, plus their employer being barred from government contracts if they were found negligent too. The devil will be in the details of the contracts, but if the EU sees Qualcomm's activities as a bribe under anti-corruption legislation then I wouldn't be surprised if they announce that they are going after Apple as well pretty soon.
Citation needed, and no, the US Army's claims that lack supporting evidence do not count - especially given they generally include the word "may".
Sure, DJI is definitely doing *some* data collection (as are most of the action cam/drone systems, either directly through the device or through on-line accounts associated with it) because they tell you so, but they're also claiming to be actively taking steps to improve enduser privacy and have blocked third party apps that have been caught doing so. Like MS Windows' telemetry, it's 100% clear that some data is being collected, but the actual extent of it seems to be based mostly speculation and rumour rather than fact and I've yet to see any really definitive articles that quantify with actual proof the scope of what is being collected and what countermeasures a privacy concious user might take to minimise the "damage" (and any operational compromises those countermeasures might entail). For instance, you claim that DJI is tracking location data in realtime using your phone, which is certainly possible, but the handset-drone comms uses the controller radio transmitter and the phone is USB tethered, so you should be able to put the phone into flight mode and simulate being in an area with no reception - or even just *be* in an area with no reception to prevent that from happening - unless they retrospectively upload it later, but again, I've not seen any definitive articles with evidence to back this up.
So, for anyone considering a drone purchase or that already has one and is getting concerned about the levels of tracking, does anyone have any decent links on this?
I don't think there's going to be an IPO (or ICO for that matter, given the number of companies jumping on that bandwagon), at least not in the near future. According to CNBC they might also be up for sale. I'm sure there would be some white knight willing to try and ride to the rescue, but at this point I fear it's going to take more than lower prices and a couple of new mounting options to turn things around. More likely they'll either end up part of some tech multi-national like Softbank or grabbed for their camera tech and patent portfolio by one of the larger drone manufacturers - Parrot or Yunneec, perhaps.
Yes, I do realise that - but it doesn't change the situation that *all* the BSD devs were kept out of the loop regardless of which family they work on. If you consider that there is still a lot of overlap between the two teams in terms of the code and contributors, then it would be kind of hard for FreeBSD to be making changes and testing them - especially if they wanted to roll them out publically like Linux did - without at least some of the OpenBSD devs either being in the loop or figuring out that something was up - and that then becomes a risk of premature and uncontrolled disclosure. Yes, it's possible that the FreeBSD security team could have kept everything under wraps, but from Google's point of view that's not the question they would have been considering; they'd have been considering how likely it was each potential insider was to result in a breach of the embargo. We now know FreeBSD wasn't in the loop, and we have to think they might consider that Theo might be a problem for maintaining the embargo, so regardless of whether they just treated all of BSD as a single entity or that the "Chinese walls" between the two teams wouldn't be strong enough, the end result is the same - a lot of BSD users, in all families, in a race to secure systems before the exploits hit.
That's exactly my reasoning. By comparison the Pentium recall was easy; die and pin-out compatible CPUs were still in production, but even for a partial recall here it's likely Intel would have to not only dust off old silicon designs, but the associated fabrication processes and packages as well. And that's before you start to factor in the higher proportion of CPUs now that are not really end-user, or even workshop replaceable, because they are phyically attached to motherboards rather than socketed. Their cheapest option has got to be to fight this all the way through the courts - during which time many of the CPUs will be retired - and then in the worst case pay up the legal fees and some lip-service compensation to anyone who can still find their receipts.
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans. Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either. Google's Project Zero team presumably had discussions with Intel and select others they felt they could trust about what was required to address the problem and how long it would take, and that group collectively agreed on the original release date of January 9th, plus who else to notify and when. Clearly that larger group did not include anyone in the BSD camp.
Standing up for your principles can have a cost attached, and I suspect we've just seen what that was for Theo and the BSD developers.
He's not wrong, both on the recall (which I'm not holding my breath on - I fully expect Intel to fight that to the bitter end given how much more painful than the Pentium replacements that would be for them) and the handling of the entire situation. There's clearly been a very high bar set betweeen those who were given the heads-up and those who were not, especially amongst service providers where it appears that only the *really* big players were in the loop. In the case of BSD devs specifically being left out of the loop though, perhaps Theo needs to take Linus' advice to Intel and a good hard look in the mirror as I seem to recall a similar incident not so long ago where the BSD devs were in the loop, but Theo refused to play ball and turned it into a free for all. I don't have the slightest problem with Theo standing up for his principles, but to do so without expecting there to be some rather obvious blowback should there be a similar situation in the future is rather naive, to say the least.
Which is pretty much the advice that was given while this was still in the submission queue; get a small laptop or a tablet and keyboard combo. Two comments and /thread. Why this made the front page - as a full story no-less - is beyond me, maybe they're fresh out of Trump and Bitcoin stories and were getting desparate to justify their salary or something...
That's where the geneticists come in, and this is covered in the article too. Even in *extremely* remote tribes - those in Brazil, for instance - there is genetic evidence of interbreeding with adjacent tribes, who interbreed with their adjacent tribes, and so on. Just because Tribe A has never mingled directly with true outsiders, doesn't mean their cousins in Tribe B, don't have cousins over in Tribe C that don't do so; by land for the Amazonian tribes, by sea (Polynesians, etc.) for the Aborigine. Once you start factoring in breeding by wider-ranging performers, traders, explorers, and (of course!) militaries and raiders, it starts becoming more and more likely that no one is truly isolated from everyone else for long. Obviously Chang's work is just a mathematical model and his numbers are the result of that, but it does seem to correlate very closely with genetic evidence so, while there will always be outliers, for the majority of the global population at least he's probably not all that far out of the ball park.
If that's the case after just 1,000 years, it seems quite reasonable that many, many, more lines would have existed and died out in the preceeding 10,000 or so. Especially if you were to start factoring in the more tribal nature of communities and the increased susceptibility to famine, disease, conflict, natural disasters, and so on that results.
Whether Intel knew about it before Google told them is an interesting point, and almost certainly one that will come up when (not if!) this sees the inside of a courtroom. If they knew, or even suspected, there was a potential exploit they could have silently fixed it in future CPU designs and hoped for the best. Given the timescales involved with a chip design, and the costs of fixing flaws later in the process, it's going to be quite telling to see when Intel manages to get a CPU that is immune to the problem onto the shelves and whether there are any obvious delays in shipping them.
As stands, they are almost certainly going to be launching their next generation of chips complete with the flaw and going head-to-head against a resurgent AMD Ryzen that they will be conceeding 20-30% of potential performance to on patched systems for some critical workloads like DB servers. That's going to cost them. Realistically, the generation after that is going to be a fair way down the design process too (not too far from taping out), so they're either going to have to ship that with the flaw as well, delay it to fix the problem, or ship a fixed CPU on schedule which strongly implies they've known about this much longer than six months. Either way, that's going to cost them too, and that's before you start factoring in potential damages that might be awarded by the courts.
Actually, it's kind of in the middle. The problem isn't really that Intel tried to take a shortcut and boost performance with speculative execution, it's that they tried to take too big a shortcut and dropped some (all?) of the bounds checking as well. Since bounds checking provides security, and they must know this, they basically took a design decision to roll the dice with potential security flaws in exchange for a couple of extra perforance points and, potentially, a slightly simpler design.
The current approach is to do any bounds checking *after* the speculative execution in the event that the branch is to be executed, which is what enables the kernel memory to be leaked to userspace programmes. The secure way of doing it would be to do the bounds checking *during* the speculative execution, just as you would with normal execution, and in the event of a page fault fall back to the non-speculative execution approach. That would still be slightly slower, but not as bad as forcing the non-speculative execution approach every time, which is what the patches have now enforced.
It's a deliberate design decision, they should have known what the risks were, and there are a growing number of real world instances of applications showing repeatable ~30% performance hits directly attributable to the "fixes" (I've seen one myself firsthand that resulting in a public transport time tabling system failing). It might not work out so lucrative for an individual John Q. Public in a class action lawsuit, but it's starting to look quite likely that Intel is going to get reamed in the courts over this if they can't come up with a better workaround P.D.Q.
Given the geography, "past Miami" probably means over the Glades, which is almost certainly below the maximum population density requirement, but Cuba did raise my eyebrows too. I think the clue is actually in the bit that says "thread a safe path southward", which implies a rather narrow launch corridor. Keep in mind that by the time the rocket even gets from the Cape to Miami it's travelling pretty quickly, so if there is a problem with the trajectory it could easily be outside the permitted corridor before a human has a chance to react. An on-board system could fire the detonators, igniting any high explosives and propellant within milliseconds of the rocket crossing a GPS "fence", and probably wouldn't preclude someone in Mission Control doing a manual destruct were one to be required either. You're still going to have the risk of falling debris hitting something on the ground, but that's prettty slim given the available mass, how much of it will be vaporized in the blast, and the size of the debris field increasing exponentially with altitude.
This flaw has been known about since at least October, and probably even sooner since early code to fix it starting coming out in November, which makes it seem *highly* likely that he was aware of the it and the potential impact when he took the decision to commit to the November sale. Also, as CEO, there's no way that he can plausibly claim "I didn't know about it" like the two Equifax execs who executed a stock sale just before their breach announcement did without coming across as completely incompetent and unfit for the CEO role. This reeks of insider trading, and after the outcry over the Equifax execs I can't imagine that the SEC isn't going to want to take a good hard look at this stock sale as well.
I'm sure his vested options will pay for some really good lawyers but, even so, forfeiting his job could be the least of his problems.
A lot of modern CPU speed comes from speculative execution of code in branches. In simple terms, if the CPU sees what looks like a loop it will assume it's going to be going round the loop again, look at the execution queue, and start working on any memory fetches, loading of registers, etc.so any the data is right there in the on-chip cache when needed. What seems to be happening with the flaw is that the kernel memory that should be hidden might be accessible during that speculative execution phase and can be copied before the speculative code execution is commited.
The performance hit from the fix comes if you have a system call to the OS kernel inside that loop, as the fix requires that all that data be flushed to hide kernel memory space from the user memory space every time you switch from usermode to kernel mode and back again. That seems to imply that if your code has a tight loop that makes multiple calls to the OS kernel, then you've not only lost all the performance benefits of the speculative execution and cache, but you've also had to sacrifice CPU cycles to flush it in the first place. If your code loop is being executed millions, or even billions, of times - not uncommon for some tasks - then, yeah, you could well be looking at a double-digit percentage performance hit.
This. Without being privy to the closed discussions about how to engineer the patch (which AMD was clearly a part of) we have no way of knowing whether this wasn't the agreed approach. It's not like AMD would really want Intel making the decision over whether or not each of their CPU SKUs were vulnerable, and I doubt Intel would want to make that call either - they've got more pressing matters than trying to exploit AMD CPUs to deal with and they'd have to assume AMD would eat their lunch in court if they got one wrong. Time will tell though, I'm expecting some more details to come out on this aspect of it once the embargo lifts, and I doubt AMD will be shy about it if they think Intel tried to stiff them when they do.
I think that's actually going to depend more on the OS than the vendor. The available comments, urgency, and secrecy indicates a major hardware security issue being worked around, and both Apple and Microsoft have older OSs versions that are still officially in support for security patches, so this should therefore qualify. I wouldn't put it past either of them to neglect to provide the necessary switch for those older versions in an attempt to encourage people to upgrade to their current release.
One other thing that I have noticed from the Linux patch is that it is applied by default without any attempt to tie it into the use of some other feature like hardware virtualisation which raises the distinct possibility that it might be a more general problem, and quite possibly something that could be leveraged by a malicious userspace app. If that is the case, then it's potentially a vector for malware to compromise a system which would mean it would be a bad idea to disable the code on *any* system, regardless of whether it's multiuser or not. In that situation, I'd actually kind of expect Apple and Microsoft to be thinking long and hard about whether they want the typical home user to have control or not, even before you take their "we know best" mindsets into consideration.
Linux users don't even need to compile a custom kernel (although if performance *really* matters you should probably be doing so as a matter of course) as there's a boot time option in the that can be set to disable the new Page Table Isolation mode, "nopti". Without knowing the performance hit for a specific usage case and the nature of the flaw its currently impossible to say whether using it is going to be a good idea or not, but it's nice that they at least thought to include the option. Pretty sure BSD will do the same, but feel free to place your bets on commercial operating system vendors...
Probably the same reason why they can have a nuclear weapons programme; their priorities over where to spend their miniscule GDP are completely and utterly fscked up. They do send a few of their most trusted elites overseas to study, but mostly I suspect it's down to the black market and envelopes stuffed with used notes. Just as there were a lot of Soviet weapons scientists ready to fly to Pyongyang rather than face poverty after the USSR collapsed, there are almost certainly lot of black hats willing to train the appointed NORKs in the darker side of cracking.
There's also the useful idiot / scapegoat angle, of course. A government that has trained the DPRK's hackers and an understanding of the way the DPRK operates essentially has a deniable cyberweapon they can point wherever they want just by leaking some appropriate data on the target. It's not hard to think of a few countries that might consider that black budget money well spent.
I've been firmly in the Android camp for years too (since Froyo), but I think that likely depends a great deal on your circle of acquaintances. I work in IT and civil engineering but spend a lot of my spare time doing photography, visiting galleries, and mixing with people more on the artistic/creative end of the spectrum. There's a fair bit of overlap between the two groups (quite a few in STEM fields are also into photography), but in general the former are almost exclusively Android users and the latter almost exclusively Apple, with those like myself that straddle the two groups being those more likely to be the exceptions in a given gathering. That division doesn't really surprise me; Apple marketing clearly puts style pretty high up their feature list, Android phone marketing tends to focus more the specs, so I guess they all know their target audience and are playing to it.