That statement is only supportable if vegans had a policy of annihilating meat-eating humans, which seems anathema to the vegan philosophy.
So maybe we can qualify that by saying "one day, no human will eat meat harvested from unethical or otherwise ecologically destructive livestock-farming practices."
The drug may end up in the manure, and the parasites may encounter it there at a marginally-lethal dose. When the parasite progresses further in its life cycle, its offspring may be resistant when they infect the next livestock animal.
Most parasites have a life-cycle that includes time spent outside the preferred host animal, including in zoonotic species that may not have symptomatic infections. They may acquire resistance in any stage, in any place they encountered the drug.
For AWS, as fully remote, for ridiculously high compensation, yes. Otherwise, no.
As a user, I have observed product searching and sorting to remain in a nigh-unusable state for decades now. I cannot fathom how such a state could be permitted to persist in any well-managed development team.
As a laborer, I have followed journalism covering treatment of workers, both in warehouses and on delivery routes. This led me to classify Amazon as a sociopathic corporation.
As a software professional, I have been repeatedly pinged by recruiters who seem to have no awareness of my value, or how much of my time Amazon's hiring process proposes to waste. And reports of working conditions seem strongly dependent on a random (to me) assignment to a specific team. Turnover and retention varies wildly.
The password-change form should be using a password field, and that should not be allowing any code or scripts to grab the plaintext stored in it.
If the code that compares your current password to the new password can read the plaintext of your passwords, so too could a malicious program.
Using HTML input type="password" alone is not sufficient protection. The same steps that protect password changes from malicious attackers must necessarily protect them enforcement of bad IT security policy.
I think "unsubscribe" should only be offered after a customer has been charged. Before that, it should be "cancel" or "annul".
For instance, if there is a "free trial" period, wait until after that expires, and the customer has been charged, before offering an "unsubscribe".
But aside from the hair-splitting, yes, you are absolutely correct. If I have instant buyer's remorse, I should be able to click it away just as instantly.
The time is now to dredge and dump, and build fixed oceanic platforms at their territorial extremes, while the construction crews can still breathe air and weld cheaply.
The only motivation any other country has to preserve the EEZ of Tuvalu is to prevent Chinese fishermen from overfishing that part of the ocean into a dead zone, or Chinese excavators drilling all the oil/minerals out of the seabed. So they should play up that aspect, and then they may attract the necessary investment to make a big enough pile of sand at the right coordinates.
Somebody has to stock up. Just-in-time delivery didn't, and that's why we're in this supply chain situation.
In the future, not only is it possible your money will buy you less, it is also possible that no amount of money, no matter how large, can obtain what you need.
For instance, anything with a silicon chip in it. For some goods, every known upstream retailer is out of stock, with no idea when it will be replenished, and the resellers are doing business at way above MSRP.
For some bizarre reason, management has not yet assigned a task to their programmer underlings to automated themselves out of existence. I can't imagine why.
I don't think it's a matter of trust. Management sees their job as setting priorities and resource allocation. So they shoehorn that into everything they touch. They require estimates, so they can divide impact by effort and then assign the highest ratios first, without regard to necessity or dependencies or technical debt.
As one of those back-end-preferring developers, the thing about front-end development is that the correctness of UI code is subjective, and furthermore subject to the user's opinion. On the back end, I can write heaping piles of unit tests to verify objective correctness of math and data consistency. But on the front end, this button needs to be further to the right, and labeled in a different font.
I applied once to Digium. I was rejected, because they were "looking for someone who could hit the ground running" (in those exact words). Months later, I saw that the same job posting was still up, and still active.
It may not have occurred to them to lower the speed of their onboarding treadmill and revisit rejected resumes, because I never heard from them again.
To extend the plumber analogy, prospective employers will frequently look for plumbers with specific experience in copper pipe, rigid PVC pipe, or flexible PEX pipe, as though fragmenting the plumbing space in this fashion has any bearing on whether or not the result will conform to building codes, ensure that all the drains and faucets work as expected, and generally solve any fluids transport problems that may come up without having to push the calendar to the right.
Most people look up the local business listings, pick anyone advertised as "plumber", and call to make a service appointment. Or they use a general contractor that already has a list of approved subs. Master plumbers don't have to answer little trick questions about brazing copper or about finding lead pipes in an old building. People somehow trust them to know what their job is, and do it.
Rarely, one might encounter an unreliable plumber. They might not get paid, and any other plumber is usually able to fix their botched jobs without hurting the budget much. Review sites exist to track building-trades business reputations.
But the analogy breaks, because no one trusts software and IT folks to do their jobs competently. The default assumption is that we are all know-nothing hacks who could destroy the company with one keystroke. All our knowledge is assumed to be tightly siloed, and does not transfer between similar technologies. C++ people can't do Rust or Go. Java people can't do C#. Desktop people can't do the cloud. Back-end people can't do UI. CMMI people can't be Agile.
Forever. DRM is created under the cryptographically insane belief that one can treat a person as an eavesdropper at any time after they have been an authorized recipient.
That is the unsolvable problem that guarantees DRM will never be able to create a perfect protection device that allows the company to stuff the genie back into the bottle, or the cat back into the bag, at will.