Is there a way to supress a warning where the prigin changes during the rsync?
$ rsync --archive server::somemodule/ /dest/dir
rsync: read errors mapping "/somefile" (in somemodule): No data available (61)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main...
Can anyone confirm that "prigin" should be "origin"? I.e. a typo.
If so, I don't have sufficient privileges to change it, and the edit is not long enough to go into the queue. Can someone here change it? If not, I'll take it to the SU chat room.
As I think I mentioned earlier, with the -z flag (but not without it), I'm seeing
rsync error: error in rsync protocol data stream (code 12) at token.c(476) [sender=3.2.3]
@FaheemMitha The latter. Anything that's a file name or command should be in code formatting so it's clearer and can be read as such by screen readers. The only exception, for me, is when there's too many of them and putting them all in code formatting makes the post harder to read.
I have a shell script that uses the following to print a green checkmark in its output:
col_green="\e[32;01m"
col_reset="\e[39;49;00m"
echo -e "Done ${col_green}✓${col_reset}"
After reading about Bash's ANSI-C Quoting, I realized I could use it when setting my color variables and remove the -...
@terdon That sounds like a reason. Thanks. Though I don't see why the non-code stuff can't also be unambiguous. The Romans and the Arabs really should have got together and made sure their respective alphabet and numbering systems were compatible and non-confusing.
this is somewhat opinion based, but I would use code formatting for anything that's entered on the computer, and where the exact set of characters matters. Program code, yes; filenames, yes; command line arguments, yes. The name of a program, depends, in a way: e.g. the Perl language is unambigously "Perl", but the interpreter program is "perl". (and it's case-sensitive and I'd use code formatting there).
But then I'm not sure about e.g. awk: should it be awk, Awk, or AWK? And does the distinction between the interpreter and language matter that much there?
Interestingly, the book "The AWK programming language", spells it as "AWK" in chapter titles (even those that aren't all caps) and "awk" anywhere else (both the program and the programming language).
Given it's an initialism of the authors' names (Aho, Weinberger, Kernighan), it would make sense to write it in caps. But then e.g. the POSIX text says "The awk utility shall execute programs written in the awk programming language, which is specialized for textual data manipulation." i.e. in lowercase, but italicized (of course it uses italics for other things too)
Microsoft suggests deleting your password for good. (Alternatives seem to include phone-based 2FA or facial recognition.) Am I just too prejudiced against MS, or is this objectively as bad as I think it is?
One issue is that you'd be placing an awful lot of trust in MS, but hopefully this is not a problem for most MS users. But it also sounds like you need internet connections on both the computer and your phone in order to be able to log into your computer (if you follow their recommendation to use this authentication with windows itself).
@AndrasDeak Passports are good things, as long as you can either remember them, or store them in a secure location. And of course, make them hard to guess.
2FA is a pain. And I wonder if it is really more secure to depend on phones as most services seem to be increasingly doing. They're not as secure as everyone seems to think.
the question is the attack vector it's trying to protect against, and I'd expect legitimate criticism to be along the lines of legitimate users being locked out
@AndrasDeak I think in India it's fraudsters. Apparently there are lots of them. It's practically a pandemic.
I was reading a thread in the Guardian recently about how the UK is inundated by calls, apparently mostly from India, by people trying to steal information. Very disturbing.
My point is that I'd naively think that there's a huge chunk of attackers who can easily get your password but can't easily get your phone (and vice versa to some exxtent)
@FaheemMitha phishing and other scams are a non sequitur here: if the user is willing to give access to the attacker, no amount of security will work
As I understand it, one approach is to convince the provider that you've lost your SIM, and a new one needs to be provided. In theory you are supposed to provide ID. But IDs can be stolen too.
If you can get a new SIM issued to you, the owner doesn't need to give access.
And these days, a phone is really a single point of failure. Because passwords can be reset using it, so you don't need anything else. I just did it, in fact, because a site refused to accept my password.
Arguably you'd still have to know the phone number associated with the account you're trying to gain access to. Not impossible, but not trivial either.
I'm sure many database leaks include phone numbers as well
but yeah, there's definitely an assumption of the mobile provider not being jerks
@AndrasDeak Oh, that. I had some people from my school, which I was at many years ago, try to get in touch with me. I hadn't talked to any of them for many years, but they knew my phone number.
And anyway, coming back to the original argument: even if there are attackers left who'll go to the effort of breaking your 2FA, the number of attackers will only decrease by introducing 2FA.
I have a shell script that uses the following to print a green checkmark in its output:
col_green="\e[32;01m"
col_reset="\e[39;49;00m"
echo -e "Done ${col_green}✓${col_reset}"
After reading about Bash's ANSI-C Quoting, I realized I could use it when setting my color variables and remove the -...
