cultural reviewer and dabbler in stylistic premonitions

  • 69 Posts
  • 202 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle











  • (disclaimer: this information might be years out of date but i think it is still accurate?)

    SSH doesn’t have a null cipher, and if it did, using it still wouldn’t make an SSH tunnel as fast as a TCP connection because SSH has its own windowing mechanism which is actually what is slowing you down. Doing the cryptography at line speed should not be a problem on a modern CPU.

    Even though SSH tunnels on your LAN are probably faster than your internet connection (albeit slower than LAN TCP connections), SSH’s windowing overhead will also make for slower internet connections (vs rsync or something else over TCP) due to more latency exacerbating the problem. (Whenever the window is full, it is sitting there not transmitting anything…)

    So, to answer OP’s question:

    • if you want to rsync over SSH, you usually don’t need a daemon (or to specify --rsh=ssh as that is the default).
    • if you the reason you want to use the rsync daemon is performance, then you don’t want to use SSH. you’ll need to open a port for it.
    • besides performance, there are also some rsync features which are only available in “daemon mode”. if you want to use those, you have at least 3 options:
      • open a port for your rsync daemon, and don’t use SSH (bonus: you also get the performance benefit. downside, no encryption.)
      • setup an SSH tunnel and tell the rsync client it is connecting to a daemon on localhost
      • look at man rsync and read the section referred to by this:
        • The remote-shell transport is used whenever the source or destination path contains a single colon (:) separator after a host specification. Contacting an rsync daemon directly happens when the source or destination path contains a double colon (::) separator after a host specification, OR when an rsync:// URL is specified (see also the USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION section for an exception to this latter rule).

    HTH.




















  • big oof.

    We can conclude: that photo isn’t AI-generated. You can’t get an AI system to generate photos of an existing location; it’s just not possible given the current state of the art.

    the author of this substack is woefully misinformed about the state of technology 🤦

    it has, in fact, been possible for several years already for anyone to quickly generate convincing images (not to mention videos) of fictional scenes in real locations with very little effort.

    The photograph—which appeared on the Associated Press feed, I think—was simply taken from a higher vantage point.

    Wow, it keeps getting worse. They’re going full CSI on this photo, drawing a circle around a building on google street view where they think the photographer might have been, but they aren’t even going to bother to try to confirm their vague memory of having seen AP publishing it? wtf?

    Fwiw, I also thought the image looked a little neural network-y (something about the slightly less-straight-than-they-used-to-be lines of some of the vehicles) so i spent a few seconds doing a reverse image search and found this snopes page from which i am convinced that that particular pileup of cars really did happen as it was also photographed by multiple other people.