No, we just openly talk about it a lot more than we used to.
This is partly for "good" reasons, like cultural changes that have made it possible for more children to come forward about being abused; and partly for "bad" reasons like scaremongering and clickbait.
The Bible, and even the Torah, are compilations from stories that existed before these particular books were written down. However, the character of Lilith as "first wife of Adam" is probably not something left out of the Torah, but a much later invention.
Many people are very uncomfortable with the degree to which their work and life depend on computer systems they do not understand. They feel vulnerable to computer problems, pressured into depending on more tech than they really want, and do not believe they have the knowledge or resources to remedy problems with it.
So when something goes wrong, they feel helpless. This is not unfounded, but it can often make the problem worse.
Depending on the person, this can lead to blaming or blame-dodging behavior. IT folks — did you ever ask someone what the error message was and they say "It's not my fault!" or "It's not my job to fix it, you're the computer person!" ... as if blame ever helped!
The "tech person" differs not so much in knowledge but in having a different emotional response to tech doing a weird/broken thing: when something goes wrong, they jump to curiosity. It's not "I already know how to fix this" but "We don't know what happened here yet, but we can find out." Knowledge comes from exercising this curiosity.
But this is not something that everyone can do, because people who feel unsafe don't typically go to curiosity to resolve their unsafety.
If DNS is transiently down, the most common mail domains are still in local resolver cache. And if you're parsing live user requests, that means the IP network itself is not in transient failure at the moment. So it takes a pretty narrow kind of failure to trigger a problem... And the outcome is the app tells the user to recheck their email address, they do, and they retry and it works.
If DNS is having a worse problem, it's probably down for your mail server too, which means an email would at least sit in the outbound mail spool for a bit until DNS comes back. Meanwhile the user is wondering where their confirmation email is, because people expect email delivery in seconds these days.
So yeah ... yay, tradeoffs!
(Confirmation emails are still important for closed-loop opt-in, to make sure the user isn't signing someone else up for your marketing department's spam, though.)
The only way to correctly validate an email address is to send a message to it, and verify that it arrived.
If you're accepting email addresses as user input (e.g. from a web form), it might be nice to check that what's to the right of the rightmost @ sign is a domain name with an MX or A record. That way, if a user enters a typo'd address, you have some chance of telling them that instead of handing an email to user#example.net or user@gmailc.om to your MTA.
But the validity of the local-part (left of the rightmost @) is up to the receiving server.
Any time you're turning a string of input into something else, what you are doing is parsing.
Even if the word "parser" never appears in your code, the act of interpreting a string as structured data is parsing, and the code that does parsing is a parser.
Programmers write parsers quite a lot, and many of the parsers they write are ad-hoc, ill-specified, bug-ridden, and can't tell you why your input didn't parse right.
Writing a parser without realizing you're writing a parser, usually leads to writing a bad parser. Bad parsers do things like accepting malformed input that causes security holes. When bad parsers do reject malformed input, they rarely emit useful error messages about why it's malformed. Bad parsers are often written using regex and duct tape.
Try not to write bad parsers. If you need to parse something, consider writing a grammar and using a parser library. (If you're very ambitious, try a parser combinator library.) But at least try to recall something about parsers you learned once way back in a CS class, before throwing regex at the problem and calling it a day.
(And now the word "parser" no longer makes sense, because of semantic satiation.)
By the way, please don't write regex to try to validate email addresses. Seriously. There are libraries for that; some of them are even good. When people write their own regex to match email addresses, they do things like forget that the hyphen is a valid character in domain names.
Looking up the name of a crime does not mean that you're doing that crime.
If you look up "bank robbery" that doesn't make you guilty of bank robbery. It doesn't even mean you're trying to rob a bank, or even want to rob a bank. You could want to know how bank robbers work. You could be interested in being a bank guard or security engineer. You could be thinking of writing a heist story. You could want to know how safe your money is in a bank: do they get robbed all the time, or not?
Please, folks, don't be afraid to look up words. That's how you learn stuff.
Fascists crash economies. Despite what the Marxists will tell you, fascism is terrible for capitalism. The only way fascists are ever able to show a profit is by stealing the gold out of people's teeth.
Obviously, trivially, blatantly false, because the AI safety people have been at it since long before there was anything to market. Back then, the bullshit criticism was "AI will never be able to understand language or interpret pictures; what harm could it possibly ever do?"
which I’m guessing you coined since I can’t easily find mentions of it online
Yes, that was an attempt at humor. My point was that we don't need a word fitting a specific morphology in order to talk about a topic. And when we need to be so specific as to refer to "prejudice on the basis of sexual or romantic orientation" or "violent hostility towards people perceived as gender nonconformists" we can spell those things out.
Fortunately, they also killed the mindbogglingly stupid idea of forcibly hiding https:// in the address bar. (It may be off by default, but you can turn it on.)
Also, TCP/IP requires that the server receive your IP address (or that of a proxy, VPN endpoint, etc.) so that it can send the response back. Opening a new browser window doesn't change that.
Even though going incognito prevents Chrome from saving cookies, site data and your browsing history, it doesn’t actually prevent websites or your internet service provider (ISP) from tracking you and knowing what you’re up to online. This news comes as a shock to many Chrome users but privacy experts have long warned that the browser’s incognito mode isn’t as private as you might think.
You should probably be more concerned about DNS than HTTPS. DNS is a point where government censors actually do go after web sites they don't like.