ace

"We interrupt your regular scheduling to bring you this additional bit of Factorio hype."

Flatpak uses OSTree - a git-like system for storing and transferring binary data (commonly referred to as 'blobs'), and that system works by addressing such blobs by hashes of their content, using Linux hardlinks (multiple inodes all referring to the same disk blocks) to refer to the same data everywhere it's used.

So basically, whenever Flatpak tells OSTree to download something, it will only ever store only copy of that same object (.so-file, binary, font, etc), regardless of how many times it's used by applications across the install.
Note that this only happens internally in the OSTree repo - i.e. /var/lib/flatpak or ~/.local/share/flatpak, so if you have multiple separate Flatpak installations on your system then they can't automagically de-duplicate data between each other.

A lot of that data doesn't actually exist, ostree hardlinks data blobs internally, so the actual size on disk is much smaller than most disk usage tools will show.

The # is a room alias, only ! denotes a room ID.

Room IDs are the main identifier for a room, while one or more aliases can also be assigned to it for discovery purposes.
Any server can assign aliases - and therefore also serve the room discovery, but only if the room admins allow them.

Using the Matrix HQ room as an example; #matrix:matrix.org is the canonical alias for the room, mapping to !OGEhHVWSdvArJzumhm:matrix.org.
If you want to join the room, you either need to know the ID and some information on which servers are currently part of the room, or you need to know a room alias - which can be used to query the server owning it in order to receive the information on the room and how to join it.

For example; (%23 is the HTTP entity for #, since # would otherwise be handled as a client part of the URL)

$ curl -q 'https://matrix.org/_matrix/client/v3/directory/room/%23matrix:matrix.org' | jq '.room_id, .servers[0,1]'
"!OGEhHVWSdvArJzumhm:matrix.org"
"matrix.org"
"artemislena.eu"

Let me tell you about Bumblebee and their issue #123, though that one's even worse seeing as installing system packages are done as root.

(Their install/update commands included rm -rf /usr /lib/nvidia-current/xorg/xorg)

Probably not what you're looking for, but I'm going to note that Turris make some great OpenWRT routers.
Currently running theTurris Omnia, and using both Wireguard and Yggdrasil through it.

I've been personally using KDEs Itinerary app, but it might not be what you're looking for

It could be that running the game at full speed causes some lock contention that doesn't happen when slowed down by the log stream.
Or it could also be that under normal gameplay your system spins down the harddrive to save power due to a lack of accesses, which would cause slowdowns and choppiness when the game suddenly needs to load something - also something which would be helped by running the log in the background.

For testing the second point, I'd suggest running something like this in the background while playing; (i.e. generating some constant load)

while true; do
  uptime > $HOME/workaround-test
  sleep 1
done

There's a next if [...] to_visit.include?(off_p), and I also only visit points that haven't been flood filled yet (next unless %w[. I].include? val), so there shouldn't be any superfluous testing going on.

Went back and did a quick test of thing, and yep, converting the to_visit array to a set pulls execution time down to ~600ms. But the code becomes much messier.
Going to move the mutation of the map down to the point where I pick a point for visitation instead, so I can re-use the check for already flooded tiles instead.

With the fully expanded map for the actual input it ends up working a 420x420 tile grid, and it has to do both value lookups as well as mutations into that, alongside inclusion testing for the search array (which could probably be made cheaper by building it as a set). It ends up somewhat expensive simply on the number of tests.

The sample I posted the picture of runs in 0.07s wall time though.

The squeezing component in part 2 made this really interesting.

I had a thought on a naïve solution consisting of expanding the input grid, painting all the walked pipes, and then doing a flood fill from the outside of the expanded map. There are a lot cleverer ways to do it, but the idea stuck with me and so...

The code's a bit of a mess, but I actually kind of like the result. It visualizes really well and still runs both parts in under 8 seconds, so it's not even particularly slow considering how it does it.

E.g;

def flood_fill(used: [])
  new_dim = @dim * 3
  new_map = Array.new(new_dim.size, '.')

  puts "Expanding #{@dim} to #{new_dim}, with #{used.size} visited pipes." if $args.verbose

  # Mark all real points as inside on the expanded map
  (0..(@dim.y - 1)).each do |y|
    (0..(@dim.x - 1)).each do |x|
      expanded_point = Point.new x * 3 + 1, y * 3 + 1
      new_map[expanded_point.y * new_dim.x + expanded_point.x] = 'I'
    end
  end

  # Paint all used pipes onto the expanded map
  used.each do |used_p|
    expanded_point = Point.new used_p.x * 3 + 1, used_p.y * 3 + 1

    new_map[expanded_point.y * new_dim.x + expanded_point.x] = '#'
    offsets = @links[used_p].connections
    offsets.shift

    offsets.each do |offs|
      diff = offs - used_p
      new_map[(expanded_point.y + diff.y) * new_dim.x + (expanded_point.x + diff.x)] = '#'
    end
  end

  puts "Flooding expanded map..." if $args.verbose

  # Flood fill the expanded map from the top-left corner
  to_visit = [Point.new(0, 0)]
  until to_visit.empty?
    at = to_visit.shift
    new_map[at.y * new_dim.x + at.x] = ' '

    (-1..1).each do |off_y|
      (-1..1).each do |off_x|
        next if (off_x.zero? && off_y.zero?) || !(off_x.zero? || off_y.zero?)

        off_p = at + Point.new(off_x, off_y)
        next if off_p.x < 0 || off_p.y < 0 \
          || off_p.x >= new_dim.x || off_p.y >= new_dim.y \
          || to_visit.include?(off_p)

        val = new_map[off_p.y * new_dim.x + off_p.x]
        next unless %w[. I].include? val

        to_visit << off_p
      end
    end
  end

  return new_map, new_dim
end

The naïve and unoptimized version ran in under 4 seconds for me, that's nowhere near "Time to knuckle down and actually optimize this" territory.