I find I like having "set-option -g mouse on" in ~/.tmux.conf so that mousewheel scrolling feels more natural (like it does in a local terminal).
> I find that SSH times out / disconnects if unused...
This one is a little tricky - it partly depends on the default settings of the remote sshd_config for sending KeepAlive pings (changed Debian 10 to 11, e.g) and what your local vendor-compiled ssh_config defaults look like. In general, to just solve the problem add this to your macOS ~/.ssh/config at the bottom/end:
Host *
TCPKeepAlive yes
ServerAliveInterval 300
TCPKeepAlive is what it sounds like, it's the L3 level tweak. ServerAliveInterval is a higher level ping-pong on the SSH session itself; kind of overkill to have both configured, but it Just Works(tm) for most people to have them set on their client. You can look these up in the man pages (ssh_config, sshd_config) and discover even more tweakable options than just these two I presented - some you can set server side, some client side, some both.
Side note: bash has an envvar `TMOUT` -- if that's set, bash will auto-logout if you idle in a shell. It's usually not set on most Linux server installs, just be aware it exists and is a thing to look for if you're debugging some day.
Why doesn't the author tell people to just got to https://dict.org in a browser, which is the default backend for the apps? SSL, POST queries, minimal and fast web output. Only javascript on the site is an old useless widget from a decade ago that bounced you to the internet strike of 2012. Works well even in elinks / links in a terminal if that's your thing, could probably whip up a cURL alias in minutes.
Furthermore, the last three, excepting ahdictionary.com, issue HTTPS requests per-keystroke -- needed for auto-complete.
Note however one tripping hazard with dict.org: Unencrypted port 80 i.e. "http://dict.org" is functional, does not redirect to "https://dict.org", and Firefox responds to a bare "dict.org" in its search box by first trying "http://dict.org". FF presents the dict.org home page upon getting the port 80 success response.
Gitea can import all those things, it's referred to as a Migration - you can sign up for a free account on, say, codeberg.org and give it a try before committing to running your own instance. Click the + button top right after logging in and choose New Migration -> Gitlab and follow your nose. Create an access token in your Gitlab account first, Gitea will need to use it.
> For instance, their Minesweeper guarantees that it is solvable - you will never have a 50/50 choice you cannot identify.
Alas, I've backed myself into a corner a couple of times and triggered "just gotta guess" choices in it - while it's generally good at this, it's not a 100% implementation based on my playing.
I find "Net" way more fun though for quick casual gaming, a 7x11 grid (depends on exact screen size) with wraparound enabled is a favorite for easy to tap but enough squares to make it take some time to solve (about 5 minutes per game, give or take).
> Alas, I've backed myself into a corner a couple of times and triggered "just gotta guess" choices in it - while it's generally good at this, it's not a 100% implementation based on my playing.
This should not happen because the current implementation [1] always tries to solve a randomly generated puzzle deductively, and never generates a puzzle that hasn't passed the check. (There are some shortcuts, including dynamically "perturbing" the current puzzle to make it uniquely solvable.) "Solvable" puzzles do not guarantee no backtracking though, so that's probably where you gave up. Also note that you should take account for the number of remaining mines, which can frequently be the sole information left for the very last mines.
I think you may have overlooked a logical solve. I dug into the code for his Minesweeper at one point and IIRC it works by generating random boards and putting them through a deterministic backtracking solver that gives up when faced with one of these choices. I think it then has a way of changing the board to be solvable. Or it just generates a new one, I don't remember.
I've also played it quite a bit and can't remember having any undecidable boards.
> backed myself into a corner a couple of times and triggered "just gotta guess" choices
At least for me sometimes a situation that looked like "just gotta guess" was actually solvable by knowing the total number of remaining mines, as one choice in the "guess" would imply more mines than the other.
Isn't it known how many mines are on the board, so that is not actually a problem since you could count that all of the exposed/marked mines == total # of mines?
Sure it's not something you're overlooking? Haven't encountered it myself.
Sometimes in constraint puzzles, one clue is also that there is a unique solution. So if doing one choice implies that some other choice can be arbitrary, that's not the solution.
I think it would be great if we had Code Forge index to search uniquely. In this index are only the myriad of code hosting sites around the internet - shared hosting like gitlab, github, sourcehut, sourceforge, codeberg, and all the project instances like the kernel.org, GNU Savannah, GNOME, KDE, BSD, etc. Probably hundreds of them out there, and allow people to submit their own self-hosted Gitea/Gitlab/sr.ht/etc. instances to be crawled - maybe even suggest a robots.txt entry your crawler could key in on as "yes please index me, hutbot".
I kind of think this is a dig bug -- the man page indicates you can specify `name type class queryopt` in an unargumented style, but when using IN in this fashion against `ch` it does not work correctly (testing on Debian 11 stable). Compare these 4 sets of results:
dig ch NS IN +short
dig -q ch -t NS -c IN +short
dig uk NS IN +short
dig -q uk -t NS -c IN +short
Only when using the first form do you get a comment ";; Warning, extra class option" and the incorrect results. So even when using the full pattern of un-argumented options as outlined in the man page, it fails to work as expected specifically for ch.
I put your search into SearX with a lot of the major engines enabled (Google, Bing, Qwant, Brave, DDG, etc.). Arguably, Google did a better job giving me HN results (but it's a very small sample set).
Edit: if you're not familiar with SearX, everyone who visits will get a slightly different result based on dynamic results. Even if the same person refreshes a few times the exact results and ordering will vary; I've learned to try the same search a few times to get better results, it's just a quirk of how it works and how each remote engine reacts at that given instant.
This original title also used "limits" which is more correct for the content, this link and the original title should be substituted. A "raised standard" would imply lower limits allowed by conventional use of the word/phrase.
"Texas repeatedly raises pollution limits for Cheniere LNG plant"
It's not that cut & dry, as bash is doing evaluations; 0 and 1 can both be "true" if simply used without an evaluation, but add logic and it starts to matter (grep returns 0 if hit, 1 if not).
> (Owner of Pixel 3a) Yeah, that's a bummer. There's not something else I'd rather own right now, so I'll likely keep running it for a while.
I have the 3a and 4a (non-5G), if you can find a 4a someone is trying to give away on the cheap it's basically a nicer version of the 3a IMHO. It's going to EOL in a year so I wouldn't spend much on it, but if one crosses your path for $100, well...
I find I like having "set-option -g mouse on" in ~/.tmux.conf so that mousewheel scrolling feels more natural (like it does in a local terminal).
> I find that SSH times out / disconnects if unused...
This one is a little tricky - it partly depends on the default settings of the remote sshd_config for sending KeepAlive pings (changed Debian 10 to 11, e.g) and what your local vendor-compiled ssh_config defaults look like. In general, to just solve the problem add this to your macOS ~/.ssh/config at the bottom/end:
TCPKeepAlive is what it sounds like, it's the L3 level tweak. ServerAliveInterval is a higher level ping-pong on the SSH session itself; kind of overkill to have both configured, but it Just Works(tm) for most people to have them set on their client. You can look these up in the man pages (ssh_config, sshd_config) and discover even more tweakable options than just these two I presented - some you can set server side, some client side, some both.Side note: bash has an envvar `TMOUT` -- if that's set, bash will auto-logout if you idle in a shell. It's usually not set on most Linux server installs, just be aware it exists and is a thing to look for if you're debugging some day.