OGS (online-go.com) is the predominant server for players in the Western hemisphere, and provides a modern browser based UI. Fox has a larger player base, but that player base is almost entirely in Asian timezones. Fox requires downloading a not so modern client whose UI is lacking English translation. I get the feeling that Fox has a lot of bot players in the lower ranks.

It can take a few minutes to get a match on OGS. When that happens, I take the opportunity to warm up with a few tsumego drills on goproblems.com

Hmm, both 2.16 and 2.17 worked for me. Which of the 6 puzzles in each chapter didn't work for you?

In 2.16:

3 says I'm wrong for saying its alive. It's clearly alive. It's a big black formation with one eye in the corner and one eye at the bottom

4 Says I'm wrong for saying its alive. It's clearly alive. It's a big black formation with two eyes diagonal from each other, one on the edge.

In 2.17:

2 shows me a black formation with two eyes already made and says "white to play. Make two eyes."

3 is doable but it also says "white to play" while showing a black formation.

4 shows me a black formation with two eyes already made and says "white to play. Make two eyes."

5 shows me a black formation with two eyes already made and says "white to play. Make two eyes."

6 shows me a black formation with two eyes already made and says "white to play. Make two eyes."

FYI I'm using firefox

Just an additional clarification in case the other reply doesn't help: Your phrasing of "shows me a black formation" doesn't make sense unless it is rendering the page wrong for you. All the problems you've listed show both white and black stones on the board.

For example:

> In 2.16:

> 3 says I'm wrong for saying its alive. It's clearly alive. It's a big black formation with one eye in the corner and one eye at the bottom

Should look like:

  |
  | w w w w w
  | b b b b w
  |   w   b w
  ^^^^^^^^^^^^^

(I'm also using Firefox and it's rendering correctly for me)

For me 2.16 3 looks like:

|

| B B B B B

| B B B B B

| _ B _ B B

^^^^^^^

Link to screenshot: https://imgur.com/a/odDYg9K

When I use Librewolf I think I get the intended render, but using Firefox this is what I get

The lessons are correct, but may be more obvious with better definitions.

"Alive" pieces remain permanent throughout the game. In both 2.16 examples, white can capture black by filling the gaps.

"Eyes" only have one space each and are fully surrounded by a single color. In both 2.16 examples. there are no eyes. Look at 2.17 with this new definition to see where the gaps are not yet eyes.

2.17 (3) is asking you to place a white piece within the black formation. This renders correctly for me in firefox.

Here's a link to a screenshot of what I see so you can see what I'm talking about: https://imgur.com/a/odDYg9K

Ah, I see. Not rendering white makes these lessons impossible.

It's interesting that the shading for the white pieces is preserved. I wonder if a dark mode extension is affecting the colors.

oooo I'm dumb lol. Yea I'm forcing dark mode

I'm glad we figured it out! Have fun.

The opposite color appearing on a different point is the computer playing the response to your move.

Also consider the now built-in package manager: Winget

Accidentally running a git command in the wrong folder is pretty easy to do at the command line.

I was, at one point, in the habbit of running "git checkout ." after writing some experimental code. Several times a day, or however often. So of course, I once accidentally ran that command in the wrong repo and obliterated some pending changes that hadn't been commited.

How is that git's fault?

I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key.

I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.

I don’t see anybody here claiming that’s git’s fault.

But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.

Using the command specifically designed to permanently discard work seems ”very hard” to me.

But it’s inconsistent in that. git checkout existing_branch complains with “error: Your local changes to the following files would be overwritten by checkout”* and abort, git checkout existing_directory overwrites files.

That’s what makes it easy to make that mistake, and lose data. It’s safe to use until it suddenly isn’t.

I just don't understand why someone would do git checkout existing_directory if they don't want to overwrite files, since that is all the command does.

I dunno - I can tell zsh to are-you-sure me about an `rm -rf *`, git seems like it should be able to do similarly. Or, as Mercurial does, back up overwritten files to .bak.

These are pretty light asks.

The sole purpose of git checkout -- file is to overwrite the file you explicitly listed. There should not be a confirmation by default.