I'm not particularly familiar with the industry, but I was presuming this could be first line of defense, with a smaller round of animal testing as the last line of defense to confirm the safety of the chemicals as attested by the predictions. Trust when the model says it's toxic/irritant, but verify when the model proclaim something to be safe.
If the models work, then the animal testing should be relatively humane (they should just be getting safe doses at that point) and cheaper/quicker (fewer animals made non-viable through the 'error' part of trial and error, fewer iterations that have to wait for biological processes to run the full course). However if the models are wrong, then the animal testing may bear that out.
A 40k house is not going to be an 'average suburban home' nor can it conceivably be a significant pain point mortgage wise if you are making $140k/year.
Unless you are saying you 'paid' in terms of a downpayment and ignoring the remaining value of the house.
Which is the 30% false-positive rate that I pointed out.
In other words, there is *no* singular brand/product choice to indicate wealth very well, but of those product/brand choices, the iPhone comes the *closest* to such a mythical thing. Still not to be used by itself, but as a weighted factor among other pieces of data, if you really need to care that much.
Paying by mobile can be secure. There is every probability that in this case the mechanism used for the attack is not related to anything unique to enabling paying from phone.
Roughly, they are looking for households making over 100k/year.
Sure, if you own a Bentley, you are in that group. If you don't own a Bentley, you probably still have about a 25% chance of being in that group, so it's a poor indicator because of the false negative rate.
Of course, as they point out, this isn't a good measure either. There's a 30% false-positive rate, and presumably a very high false-negative rate. It's just *less* severe than brands like Bentley or Ferrari.
I wager the attendant didn't catch on for a while. Generally nowadays the systems are *supposed* to only dispense if the customer has given payment info or the attendant has turned it on. In fact, most of the time when I go to a gas station now, I've set up payment before I even leave the car and just get out and pump. A station attendant may have a hard time distinguishing someone paying by mobile from someone who made it dispense gasoline otherwise, depending on how it works. Note it says it went on for 90 minutes, then he shut it down, *then* he called police. It also says he "got an emergency kit"., which may have been how he was describing the fuel shut off (his English may not have been the best). Him describing the system being non-responsive doesn't mean he sat there for a long time trying to overcome the situation, it just speaks to his surprise.
Interestingly enough, IPMI's current auth design was done in 2004. Somehow despite being at least two years after SNMP proved someone was thinking about how to derive a shared secret without using it directly.
Somehow despite SRP being a well known thing that would neatly slot into IPMI, no one has bothered to amend the IPMI spec to remove the need for the server to know the password, and also to amend the poor decision for the server to send HMAC first.
No matter your vendor, this is a dumb idea. Any 'firmware' or "appliance" should not be easily/directly on the internet.
First you have the problem that even 'reputable' companies lag far far behind the likes of Microsoft, RedHat, and such in changes. Even if they have the will and the resources, the security researchers go to other companies first and put them under embargo.
Second, no one keeps their firmware up to date, even if there exists firmware that does have all the fixes. The really fun part, companies that *do* routinely upgrade firmware get bitten when the vendor breaks them, and does so without a good rollback facility (after all, "downgrades" are a security risk, so a key change with a firmware update that *also* happens to be bad for your configuration, well sucks to be you).
The password is used directly as a shared secret for HMAC in IPMI. Therefore to support the ipmi protocol, the server must be able to know the plaintext of the password to a) prove to the client that they know the secret and b) to validate the HMAC sent by the client.
Another potentially tricky one is SNMP. It's a shared secret, but at least you can localize the key. Of course it is localized to an snmp engine id, so while you may not directly have the cleartext password, you can spoof a matching snmp engine id to use the localized key as if you knew the password, at least to impersonate an snmp agent.
Even on the TLS side of things, in practice things are not rosy because the vast majority of this class of devices have a self-signed cert, with all automation disabling cert validation and all users blindly clicked 'continue' at the warnings (there's no harsher message for "we have a conflicting stored cert" than "this is a self signed cert we haven't seen before")
1) Sure, part of the incentive package is a reduced tax rate, which doing thie math, 50% of taxes on X income is better than 100% of taxes on 0 income. This is mostly straightforward, though if the presence of the company attracts population growth and part of the calculus for affording infrastructure and emergency services and such would be the taxes you opted out of, that could be bad.
2) Frequently included in these incentives are *refundable* tax credits. Such a tax credit will probably materialize as straight out giving them money (else why bother making them refundable tax credits, non-refundable would be the same).
3) Another fuzzy one is they often include "infrastructure" spending. In theory, infrastructure spending is presented as elevating conditions for *everyone*, but even if that's true it's spending money you thought you wouldn't otherwise spend. In practice those improvements are going to be done in ways the company would appreciate.
It's hard to tell at a glance, reporting focuses on 'X billion dollar incentive packages' with very little effort made for breaking down how much of that is hypothetical forfeit revenue, and how much is actually money that would come out of the government. Also why the numbers look so much higher in some places than others. A locality with high tax rates can be seen to offer a larger cut because their nominal rate is high, and a low tax rate location will have a smaller *looking* number in the headlines, but the company may be paying lower taxes than the 'big' incentive package elsewhere.
FPGAs would not do a better job than ASICs at mining. An FPGA is however at least vaguely useful after a crash in the cryptocurrency for other things, whereas ASICs would likely be utterly useless.
Well, it's also possible to induce scarcity. If it were a truly competitive market, then a competitor would have probably do a crazy production ramp up to mitigate.
As it stood, nVidia limited their production ramp up (precisely because they expected the bottom to fall out of the market and didn't want to be stuck with a glut when it fell) and instead did various things to try to throttle customers buying GPUs (although they explicitly gave crypto-mining an exemption to some of those, because they had such mixed feelings on it).
My point was not about hardware, it is that the purported savings of going to a cloud vendor are about acquiescing to that vendor's decisions that are likely less than what you had. Sometimes they are right and you overreacted and paid too much for something too crazy, sometimes they are cutting corners because the business arrangement doesn't require them to take care of things that you formerly had covered, but took for granted, or assumed it 'came along' or otherwise didn't think you needed to worry about it, because no one else seems to talk about worrying about it.
Sure the fact that a business of some scope is tied to a specific personal credit card seems problematic, but then again if it is a small business, this isn't too strange.
That is a very interesting point as well. Internally whatever 'formal' agreements may be there, the business reality has the opportunity to overrule the 'letter-of-the-law', which is a very valuable facet of having your requirements fulfilled even in the face of unexpected circumstances.
Meanwhile in any outsourcing arrangement, they don't really care about your business success, they care whether they fall within the narrow wording of the contract. If that contract has a loophole that's easier than fixing the problem, loophole it is.
Yes, but at the exact same time you see articles saying to "go all in with ".
By the time you get to a multi-cloud provider, are you really getting the value for your dollar as you relinquish control? It multiplies the cost of your infrastructure to cope with an entirely new non-technical burden. Also if you are not in the US, using all of the top cloud providers (Amazon, Microsoft, Google, IBM) still puts you at risk of the government messing with your business (doesn't need to be even vaguely criminal looking, some international tariff//tax gets levied and you could be screwed). Yes those companies do their best to have somewhat sovereign subsidiaries, but the head of the company is ultimately US jursidiction...
One, note that just because they are a big name, it does not mean all their decisions are bullet proof guaranteed the best. Dropbox has the exact opposite story to tell.
For another, Netflix has a rather special position. They are *the* go-to reference customer for AWS. Amazon with almost every other breath references just how *awesome* Netflix is doing with AWS. As such, they assuredly have special status, Amazon is not going to just screw with Netflix because the second Netflix so much as whispers a negative AWS experience, their biggest reference customer has gone bad. If there is *any* company on the face of the Earth that can get away with single-sourcing from a cloud vendor, it's Netflix.
For the 98% of customers who are not highly prized marquee customers.. Well your experience will deviate from stories about Netflix.
Well, one it is an oversimplification for me to imply it's always cheaper to own your own, but in a lot of cases it is cheaper. The fundamental reality is that it is renting vs. owning, and in renting the owner is having to charge to have profit above and beyond what is theoretically possible to do yourself. Of course, the gap between theory and practice is huge, but in some cases it can be close.
Three major contributors that differ to host in house versus cloud: -Equipment -Labor -Real estate/locality.
On equipment, some major enterprisey types save money largely because the cloud providers are willing to cheap out on hardware more than they did, and to skip service and warratny fees. In other words, they got traction by gouging customers ever so slightly than the "accepted" vendors. Of course, the providers of servers to those cloud datacenters are perfectly happy to sell to your business, and at small scale the delta is negligible.
Labor savings are, well, overstated. The good news is they are taking care of the physical infrastructure, but in its place you have at least as complicated 'cloud' infrastructure to manage.
Real estate gets to be be the more complicated situation. If your ambitions for your business are modest, then you may not derive value over having the ability to place in datacenters all around the world. If you are a pure 'software/information' play with multi-national ambitions, then it's probably cheaper to get reach through a cloud provider. If however you deal with physical goods, then you get sufficiently embroiled in all sorts of complexities in dealing with geographies anyway, that cloud provider might not be sparing you from much.
They can't knock out the connection between a local monitoring server and the local equipment.
In this case, they might have lost *a* power plant remotely, but could still reach out to the local personnel and *they* would still see monitoring.
Also, the same ISP can knock out your ability to manage your cloud hosted infrastructure, so the cloud adds a party to screw you over without removing any.
Ah, but SLAs cost money, and part of the cloud movement has been "see, these vendors can make hosting cheaper than it used to be", precisely because all they have to do when they screw you over is say "whoops, sorry", and as such don't need to invest in *too* much resiliancy and don't have to worry too much about liability.
If you do a second location, you may be inclined to go to another "availability zone" at the *same* provider, and then watch all your redundancy go poof.
Some may say "oh that's why you should have *mulptiple* cloud vendors too", which greatly increases cost and complexity when even *one* vendor is more expensive than owning your own equipment.
The failure modes in a hosting service are more insidious, when they don't want your services to be up, they take them down, all at once. No amount of being good about your availability zones and such will stand up to the reality that your vendor can shut down *everything*.
Exacerbated by the reality they have so *much* activity, they can't have humans police it so instead they have automation systems that are prone to false positives.
When you host yourself, the fundamental operational technology failure modes you can deal with. Of course if your network provider decides something similar, they can mess you up.
In the situation given in the summary, local monitoring of each power facility would not carry the "some other company disables you" problem. This is why I get bothered when people make some cloud service a prereq for relatively simple voice recognition. That sort of workload can be handled locally nowadays, the dependency just makes the feature more fragile.
If an unsolicited ask for employment, or even a submission to a job opening, I don't expect a reply if negative.
By the same token, I don't read all job postings out there nor do I bother to reply to unsolicited recruiter messages.
On the other hand, once there's been a two-way conversation between humans, I expect a conclusive message at the end from whichever party, and thus far that's the way it has always been for me.
Slashdot Mirror
I'm not particularly familiar with the industry, but I was presuming this could be first line of defense, with a smaller round of animal testing as the last line of defense to confirm the safety of the chemicals as attested by the predictions. Trust when the model says it's toxic/irritant, but verify when the model proclaim something to be safe.
If the models work, then the animal testing should be relatively humane (they should just be getting safe doses at that point) and cheaper/quicker (fewer animals made non-viable through the 'error' part of trial and error, fewer iterations that have to wait for biological processes to run the full course). However if the models are wrong, then the animal testing may bear that out.
A 40k house is not going to be an 'average suburban home' nor can it conceivably be a significant pain point mortgage wise if you are making $140k/year.
Unless you are saying you 'paid' in terms of a downpayment and ignoring the remaining value of the house.
Which is the 30% false-positive rate that I pointed out.
In other words, there is *no* singular brand/product choice to indicate wealth very well, but of those product/brand choices, the iPhone comes the *closest* to such a mythical thing. Still not to be used by itself, but as a weighted factor among other pieces of data, if you really need to care that much.
Paying by mobile can be secure. There is every probability that in this case the mechanism used for the attack is not related to anything unique to enabling paying from phone.
Roughly, they are looking for households making over 100k/year.
Sure, if you own a Bentley, you are in that group. If you don't own a Bentley, you probably still have about a 25% chance of being in that group, so it's a poor indicator because of the false negative rate.
Of course, as they point out, this isn't a good measure either. There's a 30% false-positive rate, and presumably a very high false-negative rate. It's just *less* severe than brands like Bentley or Ferrari.
I wager the attendant didn't catch on for a while. Generally nowadays the systems are *supposed* to only dispense if the customer has given payment info or the attendant has turned it on. In fact, most of the time when I go to a gas station now, I've set up payment before I even leave the car and just get out and pump. A station attendant may have a hard time distinguishing someone paying by mobile from someone who made it dispense gasoline otherwise, depending on how it works. Note it says it went on for 90 minutes, then he shut it down, *then* he called police. It also says he "got an emergency kit"., which may have been how he was describing the fuel shut off (his English may not have been the best). Him describing the system being non-responsive doesn't mean he sat there for a long time trying to overcome the situation, it just speaks to his surprise.
Interestingly enough, IPMI's current auth design was done in 2004. Somehow despite being at least two years after SNMP proved someone was thinking about how to derive a shared secret without using it directly.
Somehow despite SRP being a well known thing that would neatly slot into IPMI, no one has bothered to amend the IPMI spec to remove the need for the server to know the password, and also to amend the poor decision for the server to send HMAC first.
No matter your vendor, this is a dumb idea. Any 'firmware' or "appliance" should not be easily/directly on the internet.
First you have the problem that even 'reputable' companies lag far far behind the likes of Microsoft, RedHat, and such in changes. Even if they have the will and the resources, the security researchers go to other companies first and put them under embargo.
Second, no one keeps their firmware up to date, even if there exists firmware that does have all the fixes. The really fun part, companies that *do* routinely upgrade firmware get bitten when the vendor breaks them, and does so without a good rollback facility (after all, "downgrades" are a security risk, so a key change with a firmware update that *also* happens to be bad for your configuration, well sucks to be you).
The password is used directly as a shared secret for HMAC in IPMI. Therefore to support the ipmi protocol, the server must be able to know the plaintext of the password to a) prove to the client that they know the secret and b) to validate the HMAC sent by the client.
Another potentially tricky one is SNMP. It's a shared secret, but at least you can localize the key. Of course it is localized to an snmp engine id, so while you may not directly have the cleartext password, you can spoof a matching snmp engine id to use the localized key as if you knew the password, at least to impersonate an snmp agent.
Even on the TLS side of things, in practice things are not rosy because the vast majority of this class of devices have a self-signed cert, with all automation disabling cert validation and all users blindly clicked 'continue' at the warnings (there's no harsher message for "we have a conflicting stored cert" than "this is a self signed cert we haven't seen before")
It's complicated.
1) Sure, part of the incentive package is a reduced tax rate, which doing thie math, 50% of taxes on X income is better than 100% of taxes on 0 income. This is mostly straightforward, though if the presence of the company attracts population growth and part of the calculus for affording infrastructure and emergency services and such would be the taxes you opted out of, that could be bad.
2) Frequently included in these incentives are *refundable* tax credits. Such a tax credit will probably materialize as straight out giving them money (else why bother making them refundable tax credits, non-refundable would be the same).
3) Another fuzzy one is they often include "infrastructure" spending. In theory, infrastructure spending is presented as elevating conditions for *everyone*, but even if that's true it's spending money you thought you wouldn't otherwise spend. In practice those improvements are going to be done in ways the company would appreciate.
It's hard to tell at a glance, reporting focuses on 'X billion dollar incentive packages' with very little effort made for breaking down how much of that is hypothetical forfeit revenue, and how much is actually money that would come out of the government. Also why the numbers look so much higher in some places than others. A locality with high tax rates can be seen to offer a larger cut because their nominal rate is high, and a low tax rate location will have a smaller *looking* number in the headlines, but the company may be paying lower taxes than the 'big' incentive package elsewhere.
I presume he meant some sort of motherboard with a graphics chip on the board, which I'm guessing exists still, for a ThreadRipper socket...
Alternatively get one of those unwanted low end, but still discrete...
FPGAs would not do a better job than ASICs at mining. An FPGA is however at least vaguely useful after a crash in the cryptocurrency for other things, whereas ASICs would likely be utterly useless.
Well, it's also possible to induce scarcity. If it were a truly competitive market, then a competitor would have probably do a crazy production ramp up to mitigate.
As it stood, nVidia limited their production ramp up (precisely because they expected the bottom to fall out of the market and didn't want to be stuck with a glut when it fell) and instead did various things to try to throttle customers buying GPUs (although they explicitly gave crypto-mining an exemption to some of those, because they had such mixed feelings on it).
My point was not about hardware, it is that the purported savings of going to a cloud vendor are about acquiescing to that vendor's decisions that are likely less than what you had. Sometimes they are right and you overreacted and paid too much for something too crazy, sometimes they are cutting corners because the business arrangement doesn't require them to take care of things that you formerly had covered, but took for granted, or assumed it 'came along' or otherwise didn't think you needed to worry about it, because no one else seems to talk about worrying about it.
Sure the fact that a business of some scope is tied to a specific personal credit card seems problematic, but then again if it is a small business, this isn't too strange.
That is a very interesting point as well. Internally whatever 'formal' agreements may be there, the business reality has the opportunity to overrule the 'letter-of-the-law', which is a very valuable facet of having your requirements fulfilled even in the face of unexpected circumstances.
Meanwhile in any outsourcing arrangement, they don't really care about your business success, they care whether they fall within the narrow wording of the contract. If that contract has a loophole that's easier than fixing the problem, loophole it is.
Yes, but at the exact same time you see articles saying to "go all in with ".
By the time you get to a multi-cloud provider, are you really getting the value for your dollar as you relinquish control? It multiplies the cost of your infrastructure to cope with an entirely new non-technical burden. Also if you are not in the US, using all of the top cloud providers (Amazon, Microsoft, Google, IBM) still puts you at risk of the government messing with your business (doesn't need to be even vaguely criminal looking, some international tariff//tax gets levied and you could be screwed). Yes those companies do their best to have somewhat sovereign subsidiaries, but the head of the company is ultimately US jursidiction...
One, note that just because they are a big name, it does not mean all their decisions are bullet proof guaranteed the best. Dropbox has the exact opposite story to tell.
For another, Netflix has a rather special position. They are *the* go-to reference customer for AWS. Amazon with almost every other breath references just how *awesome* Netflix is doing with AWS. As such, they assuredly have special status, Amazon is not going to just screw with Netflix because the second Netflix so much as whispers a negative AWS experience, their biggest reference customer has gone bad. If there is *any* company on the face of the Earth that can get away with single-sourcing from a cloud vendor, it's Netflix.
For the 98% of customers who are not highly prized marquee customers.. Well your experience will deviate from stories about Netflix.
s3 storage is *massively* expensive at scale, compared to in house. Even among cloud providers, there are competitors that are 75% less.
Well, one it is an oversimplification for me to imply it's always cheaper to own your own, but in a lot of cases it is cheaper. The fundamental reality is that it is renting vs. owning, and in renting the owner is having to charge to have profit above and beyond what is theoretically possible to do yourself. Of course, the gap between theory and practice is huge, but in some cases it can be close.
Three major contributors that differ to host in house versus cloud:
-Equipment
-Labor
-Real estate/locality.
On equipment, some major enterprisey types save money largely because the cloud providers are willing to cheap out on hardware more than they did, and to skip service and warratny fees. In other words, they got traction by gouging customers ever so slightly than the "accepted" vendors. Of course, the providers of servers to those cloud datacenters are perfectly happy to sell to your business, and at small scale the delta is negligible.
Labor savings are, well, overstated. The good news is they are taking care of the physical infrastructure, but in its place you have at least as complicated 'cloud' infrastructure to manage.
Real estate gets to be be the more complicated situation. If your ambitions for your business are modest, then you may not derive value over having the ability to place in datacenters all around the world. If you are a pure 'software/information' play with multi-national ambitions, then it's probably cheaper to get reach through a cloud provider. If however you deal with physical goods, then you get sufficiently embroiled in all sorts of complexities in dealing with geographies anyway, that cloud provider might not be sparing you from much.
They can't knock out the connection between a local monitoring server and the local equipment.
In this case, they might have lost *a* power plant remotely, but could still reach out to the local personnel and *they* would still see monitoring.
Also, the same ISP can knock out your ability to manage your cloud hosted infrastructure, so the cloud adds a party to screw you over without removing any.
Ah, but SLAs cost money, and part of the cloud movement has been "see, these vendors can make hosting cheaper than it used to be", precisely because all they have to do when they screw you over is say "whoops, sorry", and as such don't need to invest in *too* much resiliancy and don't have to worry too much about liability.
If you do a second location, you may be inclined to go to another "availability zone" at the *same* provider, and then watch all your redundancy go poof.
Some may say "oh that's why you should have *mulptiple* cloud vendors too", which greatly increases cost and complexity when even *one* vendor is more expensive than owning your own equipment.
The failure modes in a hosting service are more insidious, when they don't want your services to be up, they take them down, all at once. No amount of being good about your availability zones and such will stand up to the reality that your vendor can shut down *everything*.
Exacerbated by the reality they have so *much* activity, they can't have humans police it so instead they have automation systems that are prone to false positives.
When you host yourself, the fundamental operational technology failure modes you can deal with. Of course if your network provider decides something similar, they can mess you up.
In the situation given in the summary, local monitoring of each power facility would not carry the "some other company disables you" problem. This is why I get bothered when people make some cloud service a prereq for relatively simple voice recognition. That sort of workload can be handled locally nowadays, the dependency just makes the feature more fragile.
I interviewed for a job position, and a whole 4 months after my last interview with them, they called me back and offered the position.
By that time I had been working for 2 months at another company that I applied to after I gave up on that position.
Depends on rejected.
If an unsolicited ask for employment, or even a submission to a job opening, I don't expect a reply if negative.
By the same token, I don't read all job postings out there nor do I bother to reply to unsolicited recruiter messages.
On the other hand, once there's been a two-way conversation between humans, I expect a conclusive message at the end from whichever party, and thus far that's the way it has always been for me.