hddqsb

[Edit: The gibberish sentence "A variation moving up is also allowed." was meant to say "A variation of this solution can be used to solve the case where moving up is also allowed."]

There is a mistake in the article's statement of the problem. It says

> the possible moves are going right, down or up by one

but the actual problem (https://adventofcode.com/2021/day/15) allows moving in all four directions.

The difference is significant — the naïve attempt described in the article does not work on the actual problem.

The problem as stated in the article is actually quite interesting. The case where the only possible moves are down and right has a standard dynamic programming solution. A variation moving up is also allowed. The time complexity is O(n^2) where n is the grid size, which is faster than using Dijkstra's algorithm.

And regarding the title, I am glad you changed it, but I'd prefer something more similar to the article's new title, such as "Speeding up an Advent of Code solution with Dijkstra's". (At the time of writing, the HN title is "Finding an optimal shortest path algorithm", which doesn't provide much information, and the article's title is "Speeding up my AoC solution by a factor of 2700 with Dijkstra's".)

The unmount was just for verification. The tool is clearly intended to be used without unmounting the disk at any point.

Repeatedly copying until there are no new changes would produce a consistent image (if it terminates -- it requires the writing speed to the output device to be faster than the rate at which new data is being written to the input disk).

It may possible to stop earlier. The precise condition for producing a consistent image is as follows:

Let A[i] be the most recent modification time of block i, let B[i] be the modification time of block i at the time it was copied, and let C[i] be the time of the first modification to block i after it was copied (or infinity if the block hasn't been modified since it was copied).

We can stop if max(B) < min(C).

In detail, here is how to compute A, B, and C:

1. Initially, A[i] = B[i] = C[i] = 0.

2. When we are notified that block i has been altered, set A[i] to the modification timestamp. If C[i] == infinity, set C[i] to A[i].

3. When we copy block i, set B[i] to A[i] and set C[i] to infinity.

Except that's not how this tool works. It only does a single pass over the modified blocks as far as I can tell.[1][2]

[1] https://github.com/benjojo/hot-clone/blob/6a019efe28bdbbeeb1...

[2] https://github.com/benjojo/hot-clone/blob/6a019efe28bdbbeeb1...

I believe the reason they are called "gaping security holes" is that if nc is installed as setuid root, they allow local privilege escalation (see https://serverfault.com/questions/237584/netcat-e-the-gaping..., https://nc110.sourceforge.io/). Another explanation is that they make it trivial to create reverse shells etc. (though it is still possible to create reverse shells without -e/-c, for example using named pipes).

Nope, try it out:

  $ printf 'banana\ngrep banana\n' | grep banana | grep -v grep
  banana
  $ echo $?
  0
  $ printf 'grep banana\n' | grep banana | grep -v grep
  $ echo $?
  1

To clarify my previous comment, `grep -v grep` exits with 0 if there was a line without "grep" in the output of `grep banana`.

That's a valid concern, but in this case it won't cause problems -- grep exits with 0 if a line was selected; in the case of `grep -v grep` that means there was a line without "grep", which is what we want.

(Also @thewakalix made a good suggestion to reverse the greps.)

pgrep is great, but note that you can still encounter this problem if you run pgrep in parallel -- it will never match its own process, but it will match other pgrep processes.

So for example if you have a script that uses `pgrep -f banana` to search for a "banana" process, and you run that script twice in parallel, pgrep might see the other pgrep process and think "banana" is running even though it isn't.

I was bitten by this :)

That won't work because sshd runs the command using the user's login shell. From https://man.openbsd.org/sshd#LOGIN_PROCESS:

> When a user successfully logs in, sshd does the following:

> ...

> 9. Runs user's shell or command. All commands are run under the user's login shell as specified in the system password database.

For some reason I thought this was a standard feature of tar, and was surprised when it didn't work.

It turns out that GNU tar supports extraction of concatenated tarballs, but it requires the --ignore-zeros (-i) option:

> Normally, tar stops reading when it encounters a block of zeros between file entries (which usually indicates the end of the archive). ‘--ignore-zeros’ (‘-i’) allows tar to completely read an archive which contains a block of zeros before the end (i.e., a damaged archive, or one that was created by concatenating several archives together).

-- https://www.gnu.org/software/tar/manual/html_node/Ignore-Zer...

(As a bonus, this also works for concatenated .tar.gz files because gzip supports concatenation.)

Regarding other formats that support concatenation, the Linux kernel's initramfs format is interesting because it is based on CPIO but is explicitly defined to be the concatenation of CPIO archives:

https://www.kernel.org/doc/html/latest/driver-api/early-user...

CPIO itself doesn't support concatenation. There is a neat hack to extract such concatenated archives:

    while cpio -i; do :; done < archive.cpio

(source: https://unix.stackexchange.com/a/266090; also mentioned there is the tool skipcpio, which is part of dracut: https://github.com/dracutdevs/dracut/blob/master/skipcpio/sk...)

This hack would also work for extracting concatenating tarballs (without GNU tar's --ignore-zeros option). One annoyance is that it shows a warning when it gets to the end of the archive.

I love GitLab, and Pages access control is a great feature, but I think this was rolled out very poorly.

<rant>

The access level is "Only Project Members" by default for private projects, which I consider a breaking change because the steps I previously used to create public Pages (add .gitlab-ci.yml and push) no longer work.

The first time I tried to deploy Pages after the access control feature was enabled I wasted a lot of time because of this. When my new webpage redirect to the GitLab sign in page, I didn't bother signing in (why should I, when Pages have always been public?). I waited a day, because Pages have taken several hours to provision in the past[1]. Finally I started searching the web for why Pages was redirecting to the sign in page and found out about the access control feature.

I support having the access level "Only Project Members" by default, but I think the rollout could have been done much better. My main objections:

- There was no indication that the new webpage existed and that the issue was access control -- when I tried visiting the webpage for a non-existent project I got the same redirect. I understand why (to avoid leaking the names of private projects), but the redirected sign in page could have still shown a generic message ("project is missing or private") and mentioned that Pages are now private by default.

- The setting was not in an obvious location for me. I checked "Settings > Pages", which said the pages are served but did not give any indication that access control was enabled. There should have been a notice here saying that Pages are now private by default and that this can be changed in "Settings > General > Permissions", at least for the first few months after the rollout.

- The API [2] does not support changing the Pages access level yet, so I have to sign in to GitLab and change it manually (or fake the form submission). I want to be able to create a project with public Pages from the terminal, like I could before.

These issues could have stemmed from an assumption that developers heavily use the GitLab web interface and are always signed in. For me that is not the case.

Some small additional issues:

- The option "Pages access control" in Settings > General > Permissions is badly named because it's not clear what it means when it's toggled off. With the other options (e.g. "Issues", "Wiki", "Snippets") it's clear that toggling off the option removes the feature, but toggling off "Pages access control" could either mean "remove the access control feature" (making the pages available to everyone) or "remove the Pages feature" (making the pages available to no one). From my experiments it appears to be the second.

- The options have a glitch where toggling an option puts the corresponding access level in an inconsistent state. When the "Page access control" option of a private project is toggled off then on, the access level dropdown shows "Only Project Members" as selected but the value of the hidden <input> element is 30 (Everyone). Submitting the form sets the access level to "Everyone", as can be seen when the page refreshes. The other options have the same problem.

</rant>

[1] https://forum.gitlab.com/t/gitlab-pages-404-for-even-the-sim...

[2] https://docs.gitlab.com/ee/api/projects.html#edit-project

That's what it does. It's not that new, it's been live since Sept 27 (https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues...).

> Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix.

There is a keybinding to do simple filename completion: Alt-/ (https://www.gnu.org/software/bash/manual/bash.html#index-com...).