The other way is to get a -testing iso, but these usually are broken because most people “upgrade” their installed distro to testing instead of just install it outright.
I’ve installed Debian testing from ISO a handful of times and never had any issues.
And 99.135% of scientific papers were checked by a spell checker. This is such a non-issue. Overleaf has AI built in to help with wording; a reviewer recommended I run my paper through AI to improve it. AI is tool like any other and there’s nothing wrong with using it.
Each VeraCrypt volume contains an embedded backup header, located at the end of the volume (see above). The header backup is not a copy of the volume header because it is encrypted with a different header key derived using a different salt (see the section Header Key Derivation, Salt, and Iteration Count).
It may be possible to recover the encryption key. You might try
asking on VeraCrypt forums/mailing lists or contacting a commercial
data recovery service which understands VeraCrypt. Though I’m not
familiar with VeraCrypt so I may be misunderstanding the cited
documentation.
This doesn’t mean it’s a bad format or that it shouldn’t be used. In fact, it should still be the default unless you need something it doesn’t support or really need to reduce file size.
I rather disagree. I’ve switched to lossless WebP for all my needs. There are practically no drawbacks and I get a smaller file.
alias +='git add'
alias +p='git add -p'
alias +u='git add -u'
alias -- -='cd -'
alias @='for i in'
alias c='cargo'
alias date='LANG=C date'
alias diff='cdiff'
alias gg='git grep -n'
alias grep='grep --color=auto'
alias ll='ls -o'
alias ls='ls -vFT0 --si --color=auto --time-style=long-iso'
alias rmd='rmdir'
I also have various small scripts and functions:
a for package management (think apt but has simplified arguments
which makes it faster to use in usual cases),
e for opening file in Emacs,
g for git,
s for sudo.
And here’s ,:
$ cat ~/.local/bin/,
#!/bin/sh
if [ $# -eq 0 ]; then
paste -sd,
else
printf '%s\n' "$@" | paste -sd,
fi
Unless you go in with a byte editor, you can’t change Mercurial’s commit history. I didn’t say “fabricate”, I said “change”.
In git you also cannot change history of a commit. You can only create a new commit with a new history. You’re arguing about semantics which don’t change the end result.
The point is, with Mercurial it would be hard and the result would be utterly incompatible with any other clone of the repo: there would be no way to propagate your changes to other clones. With git, this is a standard workflow.
As the example under discussion demonstrates, it’s also impossible to propagate the changes to git clones. Since history changed, merging the pull requests shows all the differences. That’s how Linus noticed the issue.
If it was compromised account trying to sneak code into the kernel,
the attacker wouldn’t rewrite history since that would be obviously
flagged when Linus tries to merge the pull request; as demonstrated by
Linus in fact noticing the rewritten history. There was virtually no
chance that this was an attack.
Unless commits are signed, you can always rewrite history. No matter the tool. Extreme example demonstrating that this is possible is the fact that I can change my machine’s time, change my user name and reply the tool’s commands to construct whatever history I want.
find -type f -exec chmod 644 -- {} +
find -type d -exec chmod 755 -- {} +
will only affect regular files and directories. There are other type
of files (specifically block and character devices, named pipes and
sockets) which those two commands would leave unaffected. In
practice, I suspect you don’t have any of those to worry about so you
can use -find f.
So does it wait until it has found all the matches to run the command as a giant batch instead of running it as it finds matches?
Indeed. If possible, it is typically what you want (as opposed to find ... -exec ... {} \; which runs command for each found file) since it will run faster. You want find ... -exec ... {} \; if the command you’re executing can run on single file only or you’re dealing with legacy system without -exec ... {} + support.
This is not a legitimate issue. It’s like complaining that wget
reads proxy settings from /etc/wgetrc. It’s absolutely proper for
programs to read system- or user-level configuration if the
configuration is not specified via environment variables or command
line options.
The typical setting hierarchy goes something like:
I’ve installed Debian testing from ISO a handful of times and never had any issues.