Once upon a time, that would have been nearly excusable, as ftp as a common default was a thing, but locked down to uselessness. However it would be best practice to remove it.
For anything in the last decade or so, the presence of an ftp server indicates intentional set up of ftp. Again this doesn't *have* to mean it is used poorly or can be attacked, but the presence certainly suggests that it is probably being used and it's almost certainly being used insecurely by someone. Someone mentioned theoretically you can truly secure ftp, but it's so convoluted and using sftp or an https service is much easier and occam's razor would say if it is ftp, it isn't being used securely.
Ok, at some point for some things, large teams are required.
However to the extent a call must be made in personnel decisions, quality is better than quantity. Laying off one developer because they are expensive and back-filling with two of the cheapest in the world won't work the way a business would want to.
I would also say generally teams can mess things up by imagining the problem at hand suggests a large volume of people, when a small team can do the work with less inefficiency. I have worked on two very similar projects at two different companies. One fluctuated between 3-5 developers but everyone knew every one else's code and could competently cover and make great strides in functionality and fantastic support coverage even as people worked sane hours and took reasonable vacation. The other had 30 developers, had less functionality, and never did I see a customer have an issue that any one developer fully understood the relevant code, every one was incompetent outside a very narrow scope. No feature or fix could be developed without a great deal of coordination, that would inevitably have a misunderstanding and require redoing the work. Revenue for the 3-5 developer project was about 10 fold the revenue of the 30 developer project. Management's solution to that 30 person team not pulling in nearly enough revenue to cover the cost of the project? Lay off 15 and bring in 20 more from a cheaper geography from an outsourcing company no one had ever heard of. To their surprise, that did *not* in fact improve their fortunes or their user reviews.
So while there are big software projects out there that do require a big team, I would say probability is that the team doesn't have to be as big as most managers thing it would have to be.
After observing teams ranging from a handful of servers up to thousands of servers, one huge mistake I see oft repeated is a company getting all tangled up in trying to use complex advanced function they do not need, introducing fragility and hard to debug behaviors that no one quite understands.
Yes, various advanced functions have their uses, but there is a high probability that if you are trying to integrate a high number of them, you are *probably* making things needlessly difficult. Even if it could provide value, that has to be balanced against your own limits and perhaps it's better to forgo that value for the sake of staying in reach of your competency (by all means learn things and grow competency, but don't overextend yourself).
The reality is that 'devops' has achieved critical mass as a buzzword, so any particular interpretation of what that means is both correct and incorrect in the current reality.
Though it is a parody of project management methodology, it is a good way to illustrate how a vague 'methodology' can be twisted into whatever you want it to be.
You assumed that they are advocating for sequestering themselves off somewhere and doing what they want and the users having to live with it.
I on the other hand would fixate on "We are tired of being told we're socialy[sic] awkward idiots who need to be manipulated", as a way of saying programmers can work more directly with their user base without management having to micromanage that interaction. My perception stems from the reality that a group I collaborate frequently with that declares 'Agile' somehow has developers that have never had a single conversation with a user of their software, and somehow the team justifies this through application of Agile-compliant buzzwords to describe their dysfunction.
The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.
The problem is that this is mostly understood if we are being honest with ourselves, but the money train of management consultancy is running on the illusion that you can extract the essence of a quality team and inject it into a poor team and have that work. As such books with branding aligned to the buzz word of the day will minimize the awkward reality to encourage people that they can throw some money at the peddler of the methodology instead of having to pay more for people or that perhaps the people they need to succeed don't even exist.
I'd say you described the reality of any team, regardless of 'Agile' or not.
I've seen shops that said 'sorry, we can't take on this urgent requirement because we've planned out the next 2 *years* of sprints, strangled by process but they call it Agile so they think they are good.
I've seen shops that are as you imply, are aimless and don't really have any structure and when pressed say 'uhh.. Agile'.
The common thread is: if a methodology is a buzzword, it will lose any hint of meaning as it gets adopted by companies desperate to use buzz to fix real problems.
Every time, obvious observations are made and held up in hopes of driving a mindset change and every time the inconvenient ones are discarded.
The common thread is each time it's suggested you need good people and that is guaranteed to be the one thing discarded as it becomes a fad in the industry.
They all have the same goals, which is to deliver high-quality software on a continuous basis, collaboratively.
This is obviously what everyone wants and some people think waving some philosophy or methodology wand can magically make this happen. The people who kick off these pseudo-religions by reflecting upon the moments they experienced a good team making a good product, and thinking "boy if everyone pretended they were like this good team, everything would work out, here's some ways to pretend..."
If they do a good enough job naming and headlining their methodology, marketing type folks jump on board, get it out in the media, get certification mills running, advertising efforts start to coalesce around this next silver bullet that will make your terribly dysfunctional team of bottom of the barrel employees perform like the best. Key leaders get seduced by the profit potential and likely don't even realize their original vision isn't panning out.
Then when a critical mass of people observe that terrible teams are still terrible teams despite ostensibly adopting 'habits of effective people' someone inevitably proclaims a *new* methodology (which generally is the same as the old methodology) to start the cycle all over.
The reality no one wants to acknowledge is that success requires a *small* team of *really good* folks at the core. At *best* that would mean a company actually has to spend money and that is not the answer they want. At *worst* it means that the talent they need is simply unavailable at any price, or that if it is, they wouldn't have a clue how to recognize and distinguish such talent from crap.
The problem is that the web security domain is insecure as a matter of design in various ways. For the browser to protect the user without some help from the site operators, it would have to redefine what is and is not allowed for linking/form submissions. Even then it would have to totally break the way the web works, for example a site operator making a monstrosity of 'GET/delete/all/my/data' would succumb to the most trivial 'a' tag from a random site. There is a baseline of stuff the site operators must do to protect users while consuming their services.
It just so happens that the javascript runtime domain is scoped locally enough to do some useful things in a manner that can't 'bleed' into other contexts in the way other web content can. There are mechanisms (like form POST requiring an INPUT that was server side generated in a previous GET), but they are more specific/limited and generally produce additional server load to protect against things the client is in a position to protect against. This is not a matter that moves security from server to client (both cases requires client cooperating, e.g. an otherwise authenticated legitimate user running browser software they trust).
The reality is that the web began with a certain concept of the domain of a user agent and how sites interconnect and could be merged into one. One web page could freely POST to another domain and that was the security paradigm.
The problem turned out that even as a site 'trusst' the user to be authentic, that user may be under attack by other windows in the same browser, or not even visiting *your* site but a third site is using your cookies to induce the client to do undesirable things. It's not that you don't trust the client, it's that you need to protect the legitimate user of the client from attackers.
Javascript stumbled upon having a more appropriate domain to operate in, and so has become a big player in things like CSRF protection and other such security measures. Yes there are non-javascript ways of CSRF protection, but the javascript strategies for CSRF demonstrate why 'client side' security has a role in the web context when it normally is nonsense.
Of course, a lot of web security practices are obviously more duct taping together accidental behaviors that happen to break in undesirable situations, so there's a lot of ugliness in that realm in general.
Sounds like a reasonable reaction (don't fixate on Carbon emissions and end up ignoring pollution), but that's not what I generally see for rejecting AGW for policy decisions. The 'AGW might not be the case' crowd generally advocates for 'burn that coal!'
I don't see a lot of scenarios where someone is neglecting or being reckless about pollutants in their pursuit of carbon-reduction, the incliniations seem to be pretty well correlated.
The exceptions would be advocating for unregulated production of battery and solar equipment, which *could* drive pollution problems, but I do not think people are advocating for policies explicitly endorsing allowing pollution for the sake of reducing carbon.
His point was that while BitCoin is a measure of how much cpu power you cram into it, there are explorations of concepts that are not correlated with energy consumption.
I'm not particularly bullish on cryptocurrency personally, but at least on the surface of it a change to a non-energy proof rather than an energy based proof would be an answer to this specific concern.
In the interest of answering this as if it were serious, it is true that the gold standard of scientific endeavor is full-scale experiments with controls and variables. However there are plenty of scientific efforts that have to make due with at best reduced scale experiments (geology, astronomy, psychology, probably most scientific efforts). We do know at small scale the products of combustion constitute a gas that insulates heat but allows for light. We also know that the increase of this reaction correlates quite nicely with the retention of thermal energy. While the scale is such that we can't *prove* it, the simplest explanation is that there is a causative relationship.
Now let's weigh the theories by consequence of acting *incorrectly* given the two scenarios: -Global warming is not man made, but we curtail emissions anyway: We reduce our consumption of a non-renewable resource that we needed to reduce anyway. -Global warming turns out to be man made, but we fail to curtail emissions and make it exponentially worse: Massive famine and violent storms destroy so much of our society and even potentially kill us off completely.
So not only is man-made global warming the simplest explanation that fits the data, it's also the one that is by *far* the safest bet.
proof of stake seems to in theory model the current economic norms, so it would at least avoid the problem that someone throwing enough mining capacity (whether that's storage, memory, or compute) to suddenly disrupt or take over 51% of mining capacity to control the whole thing).
The problem generally is that the granularity of the model is weak and around certain concrete things.
Can process A access the memory of process B? No. Can user X open a file written privately by user Y? No.
However, if process A and B both belong to user X, then they may not be able to read each other's memory, but they do have equivalent access to the filesystem, because that wasn't the granularity OSes had in mind.
So now we have an assortment of various named facilities to go further. Mandatory Access Control, 'sandboxing', and others are important for establishing finer grained controls.
For example, my photo viewer has no particular reason to open up my private gpg key, but the traditional user/process model is not adequate to model that.
The problem is that the granularity gets tricky and convoluted, requiring a great deal of verbose pre-canned policy (selinux, apparmor) or a more manageable but less flexible set of permissions (typical of mobile app OS and web browsers). Getting both a flexible desktop *and* one adequately held to respectable security design has been a challenge.
So Microsoft doing things along these lines is commendable and not so far out of line with modern desktop OS security.
No, *that* was a problem of failing to provide adequate protection of their servers and download site from fake firmware. From all reports, this was enough to scare Apple off as a customer, but didn't actually get anywhere to have a chance to actually infiltrate anything. This is a class of attack that can be mitigated, and it is correct to select a different vendor for having better security practices to prevent an external attacker that has no business relationship with the supplier from getting in.
Bloomberg's accusation is that there was a *hardware* attack where a chip was injected and that the attack actually landed and spent a significant time having compromised the datacenters.
This is a whole different implication: -An entity with a business relationship vetted by the supplier would have been the one to execute, suggesting the supplier is at best inadequate in vetting their partners and at worst (and the bloomberg *heavily* hints it this in mildly racist ways) complicit in the attack. -Such an attack landed successfully for a significant duration.
As a few have pointed out, the far safer bet would be a firmware attack, as with the alleged approach it would be far more expensive, less likely to hit, and upon detection has no plausible deniability. The artcile smells fishy, and no other investigation can find a hint of anything to corroborate the claims.
The problem with a title like Eve Valkrie is that it was all in on VR. For a multiplayer experience, this is a challenge as the experience isn't compelling without other people, and other people won't join until it is compelling.
Contrast with, for example, Elite Dangerous where VR is core to the development, but it is but a *mode* of experiencing the game.
VR-only titles are going to be a problem, as a financial endeavor development has to stick to game that only optionally requires VR for now.
It is much the same way a game can support an RTX2080 for fancy graphics, but it better not *mandate* an RTX 2080.
In terms of people saying 'the technology isn't ready yet', frankly it's close enough to go. People go on about eye tracking, foveated rendering, and varifocal display, but far more critical would be more boring stuff, like better humidity management, optics that don't produce godrays, and perhaps some slightly high res, with emphasis on high resolution of textual elements even if the horsepower isn't there for general rendering (sure, eye tracking would facilitate foveated rendering which would be a big help, but we don't need to declare higher res is useless until we have eye tracking).
The claim is that it happened in 2015, on servers that would be decommisioned by now.
Part of the claim was that Apple reported the discovery.
So it would be 'Ford says they had gas tanks with holes in them in their 2015 F150s" and Ford saying "We checked and show no documentation supporting this claim". They didn't have to start recalling all F150s to check gas tanks for whole because some random person claimed that *Ford* claimed it. There would be an expectation that the accusation would be supported by some sort of evidence.
Here, the one named source of the original story came forward to say that he was the one who provided an actual picture of a signal coupler, and that the tone of the interviewer was basically that some *other* expert had answered 'hmm.. maybe a signal coupler?' and hypothesis upon hypothesis added up to 'we have *confirmed* that this specific pictured chip is a chinese plant'.
The most likely theory was that in 2015 SuperMicro had some accindental infection on something, and that a security team said 'other vendors have better security practices'. These 'reporters' for bloomberg, however, weren't satisfied and went running vague idea through multiple sources divorced from the actual occurrence and each time asking 'well, hypothetically...' and then presenting the result as fact.
Well actualy, not suing leads credence to the story... If you go to court, then you are putting yourself more at risk than just asking for a retraction.
However for Apple, I think asking for a retraction and trying to do it the 'gentle' way makes sense, they can't show significant fiscal harm.
I would however not be surprised to see SuperMicro go full on lawsuit, they can easily show a lot of financial harm.
I wager the result is Verizon not letting it be the device it could be: Just a small phone.
Also all the marketing BS about it being about wellness and being a phone made to *not* work as well on purpose strikes me as marketing refusing to believe there would be a market for a small phone without a 'gimmick'.
I wouldn't be surprised if behind this device were an engineering team thinking they were making a phone for people sick of the oversized phablet norm, who may be as disgusted as everyone else at the limited realization of what it is as a product...
The core tech may be capable, but the only way to buy it is as an accessory, having to pay *more* on a monthly plan than you would for a big phone, and the 800mah battery is uselessly small for that class of device, all at a purchase price higher than almost any other phone with those internals.
$350 is a lot of cash for a phone with those capabilities now. Other phones with those specs (albeit larger screen) are right about $150 at most right now.
I would likely use it as my main phone.
I'm a bit confused as to exactly how, but all the coverage suggests this is not a device that is supported unless you also buy a 'real' phone to go with it. So even if it would work, you still have to spend the money on *another* device so that you can have this device. So depending on the requirements Verizon has for a qualifying 'main' phone, that already pricey $350 becomes probably between $500 and $800.
I agree with your sentiment, that this could be a serviceable and even welcome 'main phone' based on the specs and size, but as sold it's just too expensive and Verizon is requiring it to be bought as an accessory to another device.
Slashdot Mirror
Once upon a time, that would have been nearly excusable, as ftp as a common default was a thing, but locked down to uselessness. However it would be best practice to remove it.
For anything in the last decade or so, the presence of an ftp server indicates intentional set up of ftp. Again this doesn't *have* to mean it is used poorly or can be attacked, but the presence certainly suggests that it is probably being used and it's almost certainly being used insecurely by someone. Someone mentioned theoretically you can truly secure ftp, but it's so convoluted and using sftp or an https service is much easier and occam's razor would say if it is ftp, it isn't being used securely.
Ok, at some point for some things, large teams are required.
However to the extent a call must be made in personnel decisions, quality is better than quantity. Laying off one developer because they are expensive and back-filling with two of the cheapest in the world won't work the way a business would want to.
I would also say generally teams can mess things up by imagining the problem at hand suggests a large volume of people, when a small team can do the work with less inefficiency. I have worked on two very similar projects at two different companies. One fluctuated between 3-5 developers but everyone knew every one else's code and could competently cover and make great strides in functionality and fantastic support coverage even as people worked sane hours and took reasonable vacation. The other had 30 developers, had less functionality, and never did I see a customer have an issue that any one developer fully understood the relevant code, every one was incompetent outside a very narrow scope. No feature or fix could be developed without a great deal of coordination, that would inevitably have a misunderstanding and require redoing the work. Revenue for the 3-5 developer project was about 10 fold the revenue of the 30 developer project. Management's solution to that 30 person team not pulling in nearly enough revenue to cover the cost of the project? Lay off 15 and bring in 20 more from a cheaper geography from an outsourcing company no one had ever heard of. To their surprise, that did *not* in fact improve their fortunes or their user reviews.
So while there are big software projects out there that do require a big team, I would say probability is that the team doesn't have to be as big as most managers thing it would have to be.
After observing teams ranging from a handful of servers up to thousands of servers, one huge mistake I see oft repeated is a company getting all tangled up in trying to use complex advanced function they do not need, introducing fragility and hard to debug behaviors that no one quite understands.
Yes, various advanced functions have their uses, but there is a high probability that if you are trying to integrate a high number of them, you are *probably* making things needlessly difficult. Even if it could provide value, that has to be balanced against your own limits and perhaps it's better to forgo that value for the sake of staying in reach of your competency (by all means learn things and grow competency, but don't overextend yourself).
The reality is that 'devops' has achieved critical mass as a buzzword, so any particular interpretation of what that means is both correct and incorrect in the current reality.
Though it is a parody of project management methodology, it is a good way to illustrate how a vague 'methodology' can be twisted into whatever you want it to be.
You assumed that they are advocating for sequestering themselves off somewhere and doing what they want and the users having to live with it.
I on the other hand would fixate on "We are tired of being told we're socialy[sic] awkward idiots who need to be manipulated", as a way of saying programmers can work more directly with their user base without management having to micromanage that interaction. My perception stems from the reality that a group I collaborate frequently with that declares 'Agile' somehow has developers that have never had a single conversation with a user of their software, and somehow the team justifies this through application of Agile-compliant buzzwords to describe their dysfunction.
The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.
The problem is that this is mostly understood if we are being honest with ourselves, but the money train of management consultancy is running on the illusion that you can extract the essence of a quality team and inject it into a poor team and have that work. As such books with branding aligned to the buzz word of the day will minimize the awkward reality to encourage people that they can throw some money at the peddler of the methodology instead of having to pay more for people or that perhaps the people they need to succeed don't even exist.
I'd say you described the reality of any team, regardless of 'Agile' or not.
I've seen shops that said 'sorry, we can't take on this urgent requirement because we've planned out the next 2 *years* of sprints, strangled by process but they call it Agile so they think they are good.
I've seen shops that are as you imply, are aimless and don't really have any structure and when pressed say 'uhh.. Agile'.
The common thread is: if a methodology is a buzzword, it will lose any hint of meaning as it gets adopted by companies desperate to use buzz to fix real problems.
Every time, obvious observations are made and held up in hopes of driving a mindset change and every time the inconvenient ones are discarded.
The common thread is each time it's suggested you need good people and that is guaranteed to be the one thing discarded as it becomes a fad in the industry.
And now many companies have begun the search on how to get certified X6Delta.
They all have the same goals, which is to deliver high-quality software on a continuous basis, collaboratively.
This is obviously what everyone wants and some people think waving some philosophy or methodology wand can magically make this happen. The people who kick off these pseudo-religions by reflecting upon the moments they experienced a good team making a good product, and thinking "boy if everyone pretended they were like this good team, everything would work out, here's some ways to pretend..."
If they do a good enough job naming and headlining their methodology, marketing type folks jump on board, get it out in the media, get certification mills running, advertising efforts start to coalesce around this next silver bullet that will make your terribly dysfunctional team of bottom of the barrel employees perform like the best. Key leaders get seduced by the profit potential and likely don't even realize their original vision isn't panning out.
Then when a critical mass of people observe that terrible teams are still terrible teams despite ostensibly adopting 'habits of effective people' someone inevitably proclaims a *new* methodology (which generally is the same as the old methodology) to start the cycle all over.
The reality no one wants to acknowledge is that success requires a *small* team of *really good* folks at the core. At *best* that would mean a company actually has to spend money and that is not the answer they want. At *worst* it means that the talent they need is simply unavailable at any price, or that if it is, they wouldn't have a clue how to recognize and distinguish such talent from crap.
The problem is that the web security domain is insecure as a matter of design in various ways. For the browser to protect the user without some help from the site operators, it would have to redefine what is and is not allowed for linking/form submissions. Even then it would have to totally break the way the web works, for example a site operator making a monstrosity of 'GET /delete/all/my/data' would succumb to the most trivial 'a' tag from a random site. There is a baseline of stuff the site operators must do to protect users while consuming their services.
It just so happens that the javascript runtime domain is scoped locally enough to do some useful things in a manner that can't 'bleed' into other contexts in the way other web content can. There are mechanisms (like form POST requiring an INPUT that was server side generated in a previous GET), but they are more specific/limited and generally produce additional server load to protect against things the client is in a position to protect against. This is not a matter that moves security from server to client (both cases requires client cooperating, e.g. an otherwise authenticated legitimate user running browser software they trust).
The reality is that the web began with a certain concept of the domain of a user agent and how sites interconnect and could be merged into one. One web page could freely POST to another domain and that was the security paradigm.
The problem turned out that even as a site 'trusst' the user to be authentic, that user may be under attack by other windows in the same browser, or not even visiting *your* site but a third site is using your cookies to induce the client to do undesirable things. It's not that you don't trust the client, it's that you need to protect the legitimate user of the client from attackers.
Javascript stumbled upon having a more appropriate domain to operate in, and so has become a big player in things like CSRF protection and other such security measures. Yes there are non-javascript ways of CSRF protection, but the javascript strategies for CSRF demonstrate why 'client side' security has a role in the web context when it normally is nonsense.
Of course, a lot of web security practices are obviously more duct taping together accidental behaviors that happen to break in undesirable situations, so there's a lot of ugliness in that realm in general.
Sounds like a reasonable reaction (don't fixate on Carbon emissions and end up ignoring pollution), but that's not what I generally see for rejecting AGW for policy decisions. The 'AGW might not be the case' crowd generally advocates for 'burn that coal!'
I don't see a lot of scenarios where someone is neglecting or being reckless about pollutants in their pursuit of carbon-reduction, the incliniations seem to be pretty well correlated.
The exceptions would be advocating for unregulated production of battery and solar equipment, which *could* drive pollution problems, but I do not think people are advocating for policies explicitly endorsing allowing pollution for the sake of reducing carbon.
Jupyter is something that is relatively unique, useful in its field, and *not* crammed down the throats of people for whom it isn't really relevant.
I applaud the way that project is executed, adopted, and evangelized as being on point and solidly executed...
His point was that while BitCoin is a measure of how much cpu power you cram into it, there are explorations of concepts that are not correlated with energy consumption.
I'm not particularly bullish on cryptocurrency personally, but at least on the surface of it a change to a non-energy proof rather than an energy based proof would be an answer to this specific concern.
coloration
Say what now?
In the interest of answering this as if it were serious, it is true that the gold standard of scientific endeavor is full-scale experiments with controls and variables. However there are plenty of scientific efforts that have to make due with at best reduced scale experiments (geology, astronomy, psychology, probably most scientific efforts). We do know at small scale the products of combustion constitute a gas that insulates heat but allows for light. We also know that the increase of this reaction correlates quite nicely with the retention of thermal energy. While the scale is such that we can't *prove* it, the simplest explanation is that there is a causative relationship.
Now let's weigh the theories by consequence of acting *incorrectly* given the two scenarios:
-Global warming is not man made, but we curtail emissions anyway: We reduce our consumption of a non-renewable resource that we needed to reduce anyway.
-Global warming turns out to be man made, but we fail to curtail emissions and make it exponentially worse: Massive famine and violent storms destroy so much of our society and even potentially kill us off completely.
So not only is man-made global warming the simplest explanation that fits the data, it's also the one that is by *far* the safest bet.
proof of stake seems to in theory model the current economic norms, so it would at least avoid the problem that someone throwing enough mining capacity (whether that's storage, memory, or compute) to suddenly disrupt or take over 51% of mining capacity to control the whole thing).
The problem generally is that the granularity of the model is weak and around certain concrete things.
Can process A access the memory of process B? No. Can user X open a file written privately by user Y? No.
However, if process A and B both belong to user X, then they may not be able to read each other's memory, but they do have equivalent access to the filesystem, because that wasn't the granularity OSes had in mind.
So now we have an assortment of various named facilities to go further. Mandatory Access Control, 'sandboxing', and others are important for establishing finer grained controls.
For example, my photo viewer has no particular reason to open up my private gpg key, but the traditional user/process model is not adequate to model that.
The problem is that the granularity gets tricky and convoluted, requiring a great deal of verbose pre-canned policy (selinux, apparmor) or a more manageable but less flexible set of permissions (typical of mobile app OS and web browsers). Getting both a flexible desktop *and* one adequately held to respectable security design has been a challenge.
So Microsoft doing things along these lines is commendable and not so far out of line with modern desktop OS security.
No, *that* was a problem of failing to provide adequate protection of their servers and download site from fake firmware. From all reports, this was enough to scare Apple off as a customer, but didn't actually get anywhere to have a chance to actually infiltrate anything. This is a class of attack that can be mitigated, and it is correct to select a different vendor for having better security practices to prevent an external attacker that has no business relationship with the supplier from getting in.
Bloomberg's accusation is that there was a *hardware* attack where a chip was injected and that the attack actually landed and spent a significant time having compromised the datacenters.
This is a whole different implication:
-An entity with a business relationship vetted by the supplier would have been the one to execute, suggesting the supplier is at best inadequate in vetting their partners and at worst (and the bloomberg *heavily* hints it this in mildly racist ways) complicit in the attack.
-Such an attack landed successfully for a significant duration.
As a few have pointed out, the far safer bet would be a firmware attack, as with the alleged approach it would be far more expensive, less likely to hit, and upon detection has no plausible deniability. The artcile smells fishy, and no other investigation can find a hint of anything to corroborate the claims.
The problem with a title like Eve Valkrie is that it was all in on VR. For a multiplayer experience, this is a challenge as the experience isn't compelling without other people, and other people won't join until it is compelling.
Contrast with, for example, Elite Dangerous where VR is core to the development, but it is but a *mode* of experiencing the game.
VR-only titles are going to be a problem, as a financial endeavor development has to stick to game that only optionally requires VR for now.
It is much the same way a game can support an RTX2080 for fancy graphics, but it better not *mandate* an RTX 2080.
In terms of people saying 'the technology isn't ready yet', frankly it's close enough to go. People go on about eye tracking, foveated rendering, and varifocal display, but far more critical would be more boring stuff, like better humidity management, optics that don't produce godrays, and perhaps some slightly high res, with emphasis on high resolution of textual elements even if the horsepower isn't there for general rendering (sure, eye tracking would facilitate foveated rendering which would be a big help, but we don't need to declare higher res is useless until we have eye tracking).
The claim is that it happened in 2015, on servers that would be decommisioned by now.
Part of the claim was that Apple reported the discovery.
So it would be 'Ford says they had gas tanks with holes in them in their 2015 F150s" and Ford saying "We checked and show no documentation supporting this claim". They didn't have to start recalling all F150s to check gas tanks for whole because some random person claimed that *Ford* claimed it. There would be an expectation that the accusation would be supported by some sort of evidence.
Here, the one named source of the original story came forward to say that he was the one who provided an actual picture of a signal coupler, and that the tone of the interviewer was basically that some *other* expert had answered 'hmm.. maybe a signal coupler?' and hypothesis upon hypothesis added up to 'we have *confirmed* that this specific pictured chip is a chinese plant'.
The most likely theory was that in 2015 SuperMicro had some accindental infection on something, and that a security team said 'other vendors have better security practices'. These 'reporters' for bloomberg, however, weren't satisfied and went running vague idea through multiple sources divorced from the actual occurrence and each time asking 'well, hypothetically...' and then presenting the result as fact.
Because such findings would be documented, since the allegation is that they *discovered* such chips.
Well actualy, not suing leads credence to the story... If you go to court, then you are putting yourself more at risk than just asking for a retraction.
However for Apple, I think asking for a retraction and trying to do it the 'gentle' way makes sense, they can't show significant fiscal harm.
I would however not be surprised to see SuperMicro go full on lawsuit, they can easily show a lot of financial harm.
I wager the result is Verizon not letting it be the device it could be: Just a small phone.
Also all the marketing BS about it being about wellness and being a phone made to *not* work as well on purpose strikes me as marketing refusing to believe there would be a market for a small phone without a 'gimmick'.
I wouldn't be surprised if behind this device were an engineering team thinking they were making a phone for people sick of the oversized phablet norm, who may be as disgusted as everyone else at the limited realization of what it is as a product...
The core tech may be capable, but the only way to buy it is as an accessory, having to pay *more* on a monthly plan than you would for a big phone, and the 800mah battery is uselessly small for that class of device, all at a purchase price higher than almost any other phone with those internals.
I'm cheap
$350 is a lot of cash for a phone with those capabilities now. Other phones with those specs (albeit larger screen) are right about $150 at most right now.
I would likely use it as my main phone.
I'm a bit confused as to exactly how, but all the coverage suggests this is not a device that is supported unless you also buy a 'real' phone to go with it. So even if it would work, you still have to spend the money on *another* device so that you can have this device. So depending on the requirements Verizon has for a qualifying 'main' phone, that already pricey $350 becomes probably between $500 and $800.
I agree with your sentiment, that this could be a serviceable and even welcome 'main phone' based on the specs and size, but as sold it's just too expensive and Verizon is requiring it to be bought as an accessory to another device.