I briefly looked at localstack to see how they implemented the Kenesis api and other than a `KINESIS_ERROR_PROBABILITY` option to simulate rate limiting, they did not implement any of the constraints.

Containers ran using docker are called containers, not dockers.

  $ zramctl
  NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
  /dev/zram0 zstd          3.8G  2.3G 13.2M 17.2M       4 [SWAP]

Yeah! Telling people what to do is rude!

> Anyone still using Linux on the desktop in 2026 should switch

Oh.

  * They have full sized HDMI ports 
  * They will happily run using any random old USB charger and not overheat.

> without a bulky expensive receiver box

A "receiver" has been one of the standard options for making bookshelf speakers work for more than 50 years. A receiver is also not expensive. You can get a basic used one for under $100. I paid $30 for a perfectly working 5.1 Denon receiver with HDMI.

Your problem is that you aren't even using "Modern" AV stuff. If you were, your speakers and TV would both have HDMI Arc ports. Arc has been a thing since 2009.

> That's harder than it sounds though because you have to navigate the menu blind using short and long button presses with the one button.

Or you could unplug it and plug it back in.

If they added latency to all packets then London would still have the lowest latency.

  pattern_start = 1 if half_digits == 1 else 10 ** (half_digits - 1)

  10 ** (half_digits - 1)

You were misinformed if you thought using rsync required setting up an rsync service.

  # copy all files
  COPY . .

  # install Python with uv
  RUN uv python install 3.13

  # run build process
  RUN uv run --no-dev sus

  # install Python with uv
  RUN uv python install 3.13

  # copy info for dependencies
  COPY pyproject.toml uv.lock .

  # Install dependencies
  RUN uv whatever

  # Copy over everything else
  COPY . .

  # run build process
  RUN uv run --no-dev sus

> What's the big deal that you need to call hard drives by an acronym that doesn't even mention that they're drives? No duh, of course the drives are on a network, and of course they store data.

See the problem?

Frigate is not "Cameras". Not all cameras are networked. Not all cameras record. Not all software that integrates with networked cameras is NVR software.

  SELECT *
  FROM passwords
  WHERE (password LIKE '%password%') AND (password LIKE '%123456%')
  ORDER BY user ASC
  INTO OUTFILE '/tmp/res.txt'

  Query id: 9cafdd86-2258-47b2-9ba3-2c59069d7b85

  12209 rows in set. Elapsed: 2.401 sec. Processed 1.40 billion rows, 25.24 GB (583.02 million rows/s., 10.51 GB/s.)

And this is on a Xeon W-2265 from 2020.

If you don't want to use clickhouse you could try duckdb or datafusion (which is also rust).

In general, the way I'd make your program faster is to not read the data line by line... You probably want to do something like read much bigger chunks, ensure they are still on a line boundary, then search those larger chunks for your strings. Or look into using mmap and search for your strings without even reading the files.