1,909 karma · joined September 24, 2012
this is not correct. git rebase, as with git merge, will automatically resolve conflicts using a 3-way merge algorithm.
> It will only ever modify your local
this is correct.
> unpublished commits
this is not correct. git rebase (in its default mode) rebases all commits that are not upstream onto the upstream. it has nothing to do with whether they are published or not. if you have a published feature branch, and git pull --rebase into it, git rebase will dutifully rebase all your commits.
ah, daily mail...
while it's theoretically possible for this to be caused by software, it seems more likely considering the other issues you've listed that there are some hardware issues here. linux drivers exercise the hardware differently from windows, and usually more efficiently. if your hardware is weak (particularly PSU), it can fail during intense loads. see: people blaming prime95 for crashing their computer.
if you have root access, you should be allowed to have raw device access. the problem seems to be that apple no longer believes in users owning their computers, if it ever did.
> -g, --grow: Grow (append to) the specified zip archive, instead of creating a new one. If this operation fails, zip attempts to restore the archive to its original state. If the restoration fails, the archive might become corrupted. This option is ignored when there's no existing archive or when at least one archive member must be updated or deleted.
I tested this on Linux and it appears to work as advertised. I assume the reason why it is not enabled by default is because "If the restoration fails, the archive might become corrupted".
edit: python zipfile in append mode also appears to avoid rewriting the zip file. libarchive doesn't seem to support appending to zip files.
the situation is even worse with ELF dynamic libraries due to the interaction of two rules: a) by default, all functions are exported, and b) by default, all functions can be interposed, e.g. by LD_PRELOAD. here, if you specify -fPIC in the compilation arguments (as is required to produce a modern dynamic library), inlining is totally disabled. for small functions, the call overhead can be substantial.
unshare -Ucn programedit: also https://stackoverflow.com/questions/8475448/find-merge-commi..., and also github shows this (but only for github PRs, not other merges)
You have: 2^48 byte
You want: tebibyte
2^48 byte = 256 tebibyte
2^48 byte = (1 / 0.00390625) tebibyte
how many servers do you have with more than 256 TiB of RAM?after searching for "PUT" in the manual, I found "-T, --upload-file <file> [...] If this is used on an HTTP(S) server, the PUT command will be used. Use the file name "-" (a single dash) to use stdin instead of a given file."
on Linux and all other Unix-like systems I know of, all users are allowed to list running processes and their command lines.
> Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle.
ps is not a privileged command on most systems. POSIX says "On some implementations, especially multi-level secure systems, ps may be severely restricted and produce information only about child processes owned by the user."; "severely restricted" implies that this is not a common behavior.
furthermore, the article explains clearly how to hide secret arguments from ps. that's the main point of the article.
SCRIPT_DIR="${0%/*}"
works in practically all shells, as long as the script is actually invoked by path (if you do curl script | bash, you're SOL right off the bat).the same applies with "combination of grep, awk and cut". awk contains almost all the functionality of grep, sed, and cut, so any pipeline of awk plus one of the others is almost always unnecessarily complicated. it would be like complaining "in python, string handling is so hard. look, you have to do import re; for x in re.sub(...).match(5).split(' ')[3:-5]: lst.append(x)". of course if you make it overly complicated then it will be overly complicated.
there are also too many footguns. spaces and newlines are trivial to handle in 95% of scripts, as long as you quote every expansion. as long as you never ever write cmd $file and always write cmd "$file", that solves virtually all whitespace problems. quotation marks in filenames are never interpreted in a special manner in Bourne-like shell unless you use eval, which has the same pitfalls as any other interpreted language (see python above).
actually, runescape still has 0.6 sec ticks. it has become part of the meta-game to input commands at exactly 0.6 second intervals for optimal efficiency, and is basically mandatory for high-level pvp combat.
https://oldschool.runescape.wiki/w/Tick_manipulation https://runescape.wiki/w/Tick_manipulation
https://en.wiktionary.org/wiki/hasard https://en.wiktionary.org/wiki/azar